Friday format: How to write code that no one can accompany

Thanks to the advice of experts in the field of Java, you will learn to write code that will be so difficult to maintain that anyone who will work with it after you will take years to make even the slightest changes. Moreover, if you consistently follow these rules, you will be able to guarantee yourself a lifetime job, since no one except you can figure out your code.

Basic principles

To break all the plans of your code colleague, you need to understand how he thinks. He has your giant program, but there is no time to read the entire code, much less understand it. He wants to quickly find the error and correct it so that later it does not affect the further operation of the system.
')
Here he is studying your code under a magnifying glass. At any given time, he can only see a small part of your program, and you need to make sure that he can never see the whole picture. You must make sure that he could not find what he needs for anything. And, more importantly, you must make his work so complicated that any of his omission leads to a catastrophe.

Special methods

1. Lie in the comments. It is not necessary to lie at every step: it is enough that the comments will not be associated with the code.

2. Fill the code with comments like / * add 1 to i * /, but never specify such general things as the purpose of a module or method in the code.

3. Make sure that each method does slightly more (or slightly less) than its name implies. For example, the isValid (x) method can, among other things, translate x into a binary system and store the results in a database.

4. Use abbreviations to keep your code concise. Real men never give definitions to their abbreviations: they understand them on a subconscious level.

5. To create an even greater effect, try not to use encapsulation. Those who call one or another method need all possible hints that will remind them how this method works.

6. If you are developing, say, a ticket booking system, make sure that in order to add a new airline, you need to edit the code in at least 25 different places. And never specify in the comments exactly where: those who are going to work with your code do not have the right to make adjustments to it if they have not understood it completely.

7. In order to increase efficiency, copy and paste pieces of code several times. This will be faster than creating multiple modules for reuse.

8. Never write comments to variables. Data on the use of the variable, its boundaries, permissible values, the hidden and displayed number of decimal places, the units of measurement, the form of the presentation, the rules for filling the variable (for example, the maximum number of characters or mandatory filling), whether you can trust the values ​​of this variable, and etc. should be identified already in the course of the program.

If your boss forces you to make comments, make them in the body of the method, but never write comments when declaring variables, even temporary ones.

9. Try to write as much data as possible in one line. In this case, there is no need to introduce many temporary variables, and the volume of source files is also reduced, since fewer lines and extra empty space remain.

The advantage of writing long lines of code is also the fact that developers who cannot read text with 6 pins have to increase the font to see the entries in the line.

10. Cd, npsnny bz glsnh, krch [code written without vowels, in short]. When you abbreviate the names of variables or methods, unleash your imagination and use several variations of the same word, sometimes writing it down in full. So you can deal with idlers who use text search to understand only one of the functions of your program.

Think about different spellings of names that may confuse others. For example, you can simultaneously use British color, American color and specific variants of this word like kulerz.

In the case when you write down all the names in full, each of your variables has only one spelling. A maintenance specialist can easily remember them. And once a word can be abbreviated in several ways, then you can use several different variables for the same purpose. Moreover, the software maintainer may not notice that these are several separate variables.

11. Never use automatic code alignment. Try to influence the authorities in some way so that it prohibits it in your company, arguing that automatic leveling causes unanticipated changes in the version control system or because each developer must have his own style of alignment and he should remain untouched in any of the modules written by him.

Prohibiting automatic alignment is not so difficult, even though it allows you to drastically reduce the number of keystrokes and the days spent on misunderstanding a poorly aligned code. You must insist that everyone use the same formatting style not only when storing data in a common repository, but also in the code editing process. This will cause general anger of employees, and the authorities will be forced to cancel automatic formatting to maintain calm.

After that, you can randomly align the code so that an optical illusion appears that the bodies of the cycles and conditions look longer or shorter than they should be, or the keyword else correspond to the wrong if keyword.

12. Never insert curly brackets {} in your if-else blocks unless the syntax requires it. When in your code several expressions and if-else blocks go in a row, moreover with incorrect alignment, you can even confuse an experienced colleague.

13. Strictly follow the instructions that provide for the absence of the goto operator, early exit from the cycle and its interruptions, especially when you can increase the depth of the if-else cycle by at least five more levels.

14. Use long variable names that differ from each other by just one character or case. The ideal pair of variables is swimmer and swimner.

Use all the possible drawbacks of fonts that do not allow to distinguish ilI1 | or oO08, for example, in cases with parselnt and parseInt or D0Calc and DOCalc. In this situation, the most appropriate symbol in the variable name is the letter l, since from the first time you cannot distinguish it from the constant 1.

Variable names can also differ only in case, for example, HashTable and Hashtable.

15. If the time frame is not tight, try reusing the existing names of unrelated variables. Similarly, you can use the same temporary variables for different purposes, thereby reducing the size of the stack.

It will be quite cruel if you change a variable a little: at the beginning of a very long method you can assign one value to a variable, and then somewhere in the middle quietly change it to another - say, change the origin of the index variable from 0 to 1. Just make sure That this change is not recorded in the documentation.

16. Use the lowercase letter l for the designation of constants of type long. For example, 10l is much easier to confuse with 101 than with 10L.

17. Ignore the generally accepted Java naming conventions for classes and variables, according to which, for example, classes are usually capitalized, variables - lowercase, constants - capitalized, words inside the class / variable name are capitalized. Even Sun does not follow these conventions (examples are instanceof / isInstanceOf, Hashtable / HashTable). Do not worry, the compiler will not even give you a warning.

If, nevertheless, your superiors force you to follow generally accepted agreements, every time you have a choice whether to start with a capital letter or not, write everything in capital letters or write at random, for example, you can use inputFileName and outputfilename at the same time.

Moreover, you can go to extreme measures and create your own insanely complex naming rules, and then blame others for not following these rules. The ideal option is to create as many variable names as possible, slightly differing from each other only by the register.

18. Never use i as an internal variable in a loop. You can choose any name, but not this. You can specifically use the variable i for other purposes. Similarly, you can use n as a loop counter.

19. Never use local variables. As soon as you feel that you need to make a variable local, declare it as an object or a static variable, so that it generously shares it with all the other methods of the class.

You will save yourself from unnecessary work in the future, when other methods need to declare the same variables. C ++ developers sometimes go even further and declare all possible variables global.

20. Never document errors that are not defined by the compiler. If it seems to you that the bug is hiding in the class, it is better to keep silent about it. If you have ideas about how to rebuild or rewrite the code, for the sake of all that is holy, do not write about them anywhere.

What if the programmer working with this code sees your comments? What if they are seen by the head of your company or a client? You can be fired.

21. For fun, you can pick up as many words as possible denoting the same action, for example, display, show, present. Implicitly hint that there is a slight difference between the elements of the program, which is not really there.

Conversely, if you see two similar functions that have a fundamental difference, always use the same word to describe these functions. For example, the word print means both writing to a file, printing to a printer, and output to the screen. Do not listen to anyone who will require you to define all specific terms. This would be unprofessional from the point of view of the principle of concealment of information.

22. In function names, try to use more abstract concepts, such as it, everything, data, handle, stuff, do, routine, perform, and numbers, for example, routineX48, PerformDataFunction, DoIt, HandleStuff and do_args_method.

23. In Java, all base type parameters are actually read-only, because they are passed by value. The called procedure can change these parameters, but will not have any effect on the values ​​of the variables in the calling procedure. All objects, on the contrary, can be changed, since in this case the value is passed to the link to these objects, that is, the object itself is passed by reference. Therefore, the called procedure can arbitrarily change the fields in your object.

Never say whether a method can change fields in each of the passed parameters. The names of your methods should indicate that the methods themselves can only read the values ​​of these fields, although in fact these methods can change them.

24. Never specify in the comments the units of measurement of any type of variables - input, output or parameters, whether it be feet, meters or boxes. This is of great importance not so much for the accuracy of the calculations as for the development process as a whole.

As a result, do not indicate in the comments the conversion factors for any units of measurement or the methods by which the total values ​​were obtained. A simple and very effective way is to write down the wrong units in the comments.

If you have no conscience at all, you can come up with your units of measure, calling them by your name or the name of an unknown person and without giving any explanations. If they come to you, you can say that in this way you separate integer calculations from operations on floating-point numbers.

25. Engineering calculations can be programmed in two ways. The first method is to convert all input values ​​to the SI system, perform a calculation, and then convert the output values ​​to the corresponding units of measurement. The second way: to perform calculations in various mixed measurement systems. Always choose the second method.

26. Another little-known trick. Exceptions cause too many problems. Well-written code will never let you down, so in principle you can do without exceptions: there is nothing to spend your time on them. Selecting an exception subclass is an occupation for ignoramuses who know that their program will not work.

You can significantly simplify your program by leaving the only try-catch statement in the entire application (in the main method) that calls the System.exit () method.

27. C compilers convert the expression myArray [i] into the expression * (myArray + i), which is equivalent to the expression * (i + myArray), which, in turn, is equivalent to the expression i [myArray]. Real professionals know how to use this feature for their own purposes. This method, unfortunately, is applicable only in “native” classes.

28. If you have an array of 100 elements, try to assign a specific value of 100 to variables as often as possible. Do not use static non-inherited constants instead of this value and do not refer to it through the myArray.length property. To make this value even more difficult to change, you can use other specific numbers, for example, 50 instead of 100/2 or 99 instead of 100-1. You can even more veil this value by replacing the expression a> 100 with a == 101 or the expression a> = 100 with a> 99.

You should also take into account such features as the page format, which consists of the heading x, the main text y and the notes z. You yourself can create confusion at the same time as in each of the parts of the code, and in their combination or total amount.

These time-tested methods work most effectively when there are two unrelated arrays in the program, which fortunately contain 100 elements each. For such cases, there are even more sophisticated methods. In order to lull the escort specialist, create a named constant and accidentally use the specific value 100 instead of the named constant all the time.

But besides all this, the most disgusting act in this situation will be used from time to time by other individual constants, which at a given moment of time will be 100% purely by chance. Thus, you should actually avoid using a specific name system that could bind the array name with a constant equal to its length.

29. Avoid any form of table logic. It only seems harmless, but soon leads to the fact that end users begin to understand it, and then adjust the table for themselves.

30. Try to complicate the structure of the code as much as possible. Skillful programmers can insert up to 10 pairs of parentheses () in one line and up to 20 pairs of curly braces {} in one method. Real masters are able to place the beginning and end of the block on different pages of the listing. If possible, in cycles with a condition instead of if use ternary operators [?:].

31. Look for programming aids whose authors write books more often than programs. You can go to the local bookstore and select books with lots of complicated diagrams and no code writing examples. Scroll through these books and select overly clever words. These words can be used to scare away arrogant novices who claim your place.

Your code should impress others. If others do not understand the terminology that you use, they will think that you are very clever and your algorithms are too complex. Do not use primitive vocabulary when explaining how your algorithm works.

32. Constantly make changes to your code and force users to update as often as possible: after all, no one wants to work with an outdated version of your program. Despite how well users enjoy working in your program, just imagine how much pleasure they will get after you have “improved” it.

Do not tell anyone what you changed in the new version, if this is not required of you: why talk about bugs in the old version that no one would have noticed?

33. In the section “About the program” you should indicate only the name of the program, the names of the developers, as well as a warning about copyright infringement, consisting only of legal terms. Ideally, it should contain a link to a few megabytes of code, which give a beautiful animation. But in any case it is not necessary to indicate in it the actual purpose of the program, the additional version number, the date of the last change in the program, the site on which you can receive updates, or the author’s e-mail address. With this approach, all users will soon begin to work with different versions of the program and try to install the N + 2 version at once instead of the N + 1 version.

34. The more changes you can make, the better. You do not want the same API or user interface more and more annoying your users. In addition, if you can make changes so that your users will not notice this, this is also a plus: so they will not relax, being in constant waiting.

35. If you need to write classes that another developer will use, paste the code to check environment variables (getenv () in C ++, System.getProperty () in Java) into the static nameless initializers of your classes, and then pass all your arguments to classes instead of doing the same thing in the constructor.

The advantage of this approach is that initializers are called at the time of loading modules of the program, before creating class instances, that is, as a rule, they will be executed before the main () function. In other words, the program will not be able to change these parameters before they appear in your classes: the values ​​of environment variables for users must be the same as you set them.

36. Choose for variables names that are not related to their respective labels that appear after the program starts. For example, if one of the fields on the screen is signed as Postal code, then you can give the corresponding variable the name zip.

37. Java allows you to create methods that have the same name as classes. In this case, the methods themselves may not be constructors. Use this opportunity to confuse everyone.

38. Never use placement managers. Thus, when a product support specialist adds a new field, he will have to manually select the absolute coordinates of each element on the screen. If the administration forces you to use placement managers, use one GridBagLayout mode, and select specific values ​​as grid coordinates.

39. Hammer on the Java interface. If your management begins to make claims to you, say that the Java interfaces force you to copy code into different classes that implement the same interface in the same way, and your superiors know how hard it will be to accompany this code.

Follow the example of Java AWT developers - fill your classes with rich functionality that only inherited classes can use, and perform frequent checks in your methods using the instanceof operator. It turns out that anyone who wants to use your code several times will have to extend your classes. If someone wants to use your code from two different classes, then they are not lucky - they will not be able to extend both classes at the same time.

40. Identify all your classes that have no heirs with the keyword final. In the end, you completed your work on the project, and no one can improve it by expanding your classes. Moreover, it can cause problems in the security system. That is why the java.lang.String class is declared final. If other developers on your project begin to resent, tell them that you are working to improve the performance of the program.

41. Declare as many variables as possible static. If in this program you only need one instance of a class, then this will be enough for everyone else. If other developers in your project are starting to make their claims, also tell them that you are solving a performance problem.

42. Store all unused or obsolete methods and variables in your code. If sometime in 1976 there was a need for them, what if it arises this time too? Of course, the program has changed a lot since then, but all these changes can be easily undone: you won’t reinvent the wheel (the favorite saying of the managers). If you leave in the comments all these methods and variables intact and not completely clear, then everyone who will accompany your code will also be afraid to change anything.

43. Add one comment to the makeSnafucated method / * make snafucated * /. Nowhere indicate what the word snafucated actually means. It is time for everyone to know such elementary things.

44. Change the order of the parameters in the drawRectangle method (height, width) to drawRectangle (width, height) without changing the name of the method itself. Then after several releases, change this order back. From the first time it is very difficult to guess which option is used in the program. Let us leave the task of understanding how the method works to colleagues.

45. Instead of passing parameters to one method, create as many individual methods as possible. For example, in the setAlignment (int alignment) method, the alignment variable is a constant that determines the alignment on the left and right side and in the center. Instead of one method, you can create three: setLeftAlignment, setRightAlignment, and setCenterAlignment. For even more effect, you can copy the common code into each of the methods so that it is more difficult to coordinate them.

46. The Kamasutra method has a particular advantage: it allows you to disperse the attention of both users and preparers of documentation, as well as software maintenance specialists. Create many overloaded variations of the same method, differing from each other in minor details. In my opinion, Oscar Wilde once remarked that in Kama Sutra poses 47 and 115 differed only in the fact that in the 115 pose a woman had her fingers crossed. Users also have to carefully review a long list of methods to select the most appropriate option.

In addition, due to this method, the volume of documentation increases and, consequently, the probability that it will be outdated. If your boss asks why you are doing this, explain that you are doing this solely for the convenience of users. For even greater effect, as in other cases, you can copy the common part of the code into each of the methods.

47. Declare all methods and variables public. Sooner or later someone will need it. If the method is public, it will be hard to get rid of it: it will be harder to make adjustments to the work of the program. In addition, this approach allows you to hide the real purpose of the class. If the authorities start to find fault with you, say that you are just following the traditional principles of designing “transparent” interfaces.

48. Overload functions from the C ++ library using the #define directive. In this case, everything will look as if you are using a function stored in the library, although in fact it has nothing to do with it.

49. In C ++, you can also overload the operations “+”, “-”, “*” ”,“ / ”to perform actions that are completely different from addition, subtraction, multiplication and division. If Straustrup thought of using the shift operator for I / O, wouldn't you be able to come up with something similar? When overloading the operation "+", make sure that the expression i = i + 5; nothing to do with the expression i + = 5;

50. When compiling documentation for a file, it is better to choose a random name like file, rather than such obvious names as Charlie.dat or Frodo.txt. Speaking generally, try to select random names in your examples that are as close as possible to reserved keywords.

For example, options such as bank, blank, class, const, constant, input, key, keyword, kind, output, parameter, parm, system, type, value, var and variable are perfect for the name of a parameter or variable. If you use reserved words in the names that the shell or compiler does not accept, then this is even better. If you succeed, the users will simply get confused in the keywords and the names you choose, and you will have nothing to do with it, because they just wanted to help them associate the purpose of each variable with its name.

51. Always use the special command syntax defined by your own version of the BNF (Backus-Naur form). Never explain the meaning of your syntax, presented as a set of valid and invalid commands: this will indicate a low level of your competence. The same applies to the use of syntax diagrams.

Make sure that the difference between the final characters (those that can be entered) and the intermediate characters (which are one of the syntax phrases) is not so easy to see. Try not to create visual cues in the form of a special font, color or capital letters that can help the tester to determine this difference.

In your BNF, use the same punctuation marks as in the language of commands: those who try to understand your code will think for a long time whether characters (...), [...], {...} and " ... ”part of the command you enter or their goal is to show which elements of the syntax of your BNF are mandatory, which are optional, and which are simply repeated. In the end, if they are so stupid that they cannot understand the essence of your BNF, then it simply does not make sense for them to continue working with your program.

52. The macro preprocessor offers many possibilities to confuse those who will read your code. The main technique is to place the macro at several levels deep into the code, so the rest have to look for its various components in different * .hpp files. If you insert the executable code into macros, and then place these macros in each of the * .cpp files (even in files that do not use these macros), then you maximize the number of recompiles if changes are made to the code.

53. Declaring arrays in Java can be done in various ways. You can declare the array in the old way, as in C languages, in the form of String x [] (brackets follow the variable name) or in a new way in the form of String [] x (brackets are placed after the data type). If you want to completely confuse others, you can mix both methods.

54. Java makes it possible to confuse others during the conversion of variable types. A simple example: you can, of course, convert the double type to a String directly via Double.toString (d), but it is better to do it differently by writing new Double (d) .toString. If you want, you can come up with something more sophisticated.

However, do not use the conversion methods recommended in Conversion Amanuensis. The more temporary objects the dynamic memory fills after conversion, the better.

55. Use threads as often as possible.

PS More materials on startups in our blogs on Geektimes and Megamozg .