July 18, 2010 at 18:19Code That Cannot Be Supported (Part 3, Final)
- Transfer
(The end of these two topics is the translation of the essay “Unmaintainable Code.” In the remaining chapters, the author often refers to the methods already described, doubling and tripling each of them; the presentation is greatly reduced due to the exclusion of such places.)
If you leave a bug or two in your program, then the person who comes after you will have something to have fun.
Never test code that handles any hardware or operating system failures. Anyway, this code is never executed and only delays the development process. Also, how can you check how your code handles disk crashes, file read errors, operating system crashes, and other special situations? After all, for this you will need either an extremely unreliable computer or a sandbox that will simulate it. Modern hardware never fails, and what kind of fool would write code just for testing? No, this is not interesting. If users complain, put the blame on the OS or hardware - why should they know if this is so?
If something does not work fast enough, advise the client to buy a more powerful computer. Think yourself, if you do stress testing, you can find a bottleneck, you will have to change the algorithms, or even completely redo the project. Who needs it? In addition, performance problems that arise with the customer will provide you with a free trip to some exotic place - most importantly, keep your passport ready.
(U no, the main thing is that the problem should arise on the Cote d'Azur or in Bali, and not in the Far North or in another Tmutarakan - approx.
Do not test code coverage or path coverage. Automated testing is for wimps. Find out what functions are responsible for 90% of calls to your code and write tests for them. Most likely, this way you test about 60% of your code and save yourself the remaining 40% of the effort. This will allow you to meet deadlines at the end of the project. By the time someone notices that some additional feature is not working, you’ll already have a trace of it.
Too many programmers are afraid - they are afraid of the boss, clients, mail, lose their jobs or go to court. This fear paralyzes and reduces productivity. Studies have shown that the exclusion of the testing phase allows you to perform work ahead of schedule, which eliminates most of these fears. Therefore, brave programmers do not test: their goal is to write code, and the help system and the technical support department will cope with the correction of errors.
If a person is completely confident in his abilities as a programmer, testing is not necessary. Think about it: it is obvious that testing does not solve any technical problems, no, it is a matter of emotional confidence. It is much more efficient to exclude testing and send programmers to self-esteem raising courses: after all, every change in the code will have to be tested for many years, and it is enough to complete the courses only once. The benefits are obvious and amazing.
Debug mode allows you to execute commands in it that are not part of the main mode. Transfer part of the required logic to debug mode, removing it from the main one. With proper ingenuity, the main version of the code will not even compile.
(By the way, it’s relevant - I stepped on this rake quite recently, although by accident - approx. Per.)
(This essay began to be written in 1996, so the exact advice is clearly irrelevant, and very few can follow it; only the main idea is given - approx. Per.)
The general trend in the development of programming languages is to increase the reliability and quality of protection against fools. Therefore, you should not use modern languages: insist on the oldest language that you will only be allowed to (but in which you can still program).
Hell is other people.
In this essay, there are hints on how to infuriate your companion, how to stop your boss’s attempts to get the accompanying code from you and even how to start a universal holivar on the topic of code formatting in the repository. Here are some more tips:
If your boss believes that his twenty-year experience with FORTRAN is great for modern programming, strictly follow his recommendations. As a result, the boss will trust you, your career will benefit from this, and you yourself will learn many new and interesting ways to obfuscate the code.
Do not answer the phone. Forget emails after assigning them a tracking number.
Never be vigilant in matters like Y2K. If you notice something that sneaks up at a certain moment and destroys life in the western hemisphere, do not discuss this with anyone until the time H (the moment of the event minus 4 years), when it’s time to panic and profit from panic.
(It looks like a catastrophe movie scenario, right? - approx. Per.)
Do not tell friends, acquaintances or other competent people, do not publish anything that might suggest a thought. Send one note (of normal priority) to your superiors to cover your ass. You can add this letter as an attachment to another, important and urgent. After that, you can quit quietly, knowing that at the hour of H they will beg you to return with an astronomical increase in salary.
Choose authors who are too busy writing books to program themselves. Search through local bookstores for books with tons of diagrams and no code examples. Browse through the books you have received and learn a few hundred obscure but beautiful words that you can use to intimidate the insignificants following you. Your code should be impressive. The vast incomprehensible vocabulary makes people think that you are very smart and your algorithms are very complex. For completeness, avoid the banal analogies in the explanations.
Geniuses are not too worried about whether their average colleagues keep up with them (and some also experience sadistic pleasure from their suffering), and thus often lead their project to death. Behave even if you are not a genius. At least tell everyone that if they were smart enough, they would have no problem understanding your ingenious code.
(It contradicts the previous point, but it’s much simpler - approx. Per.)
One C programmer was annoyed by a company policy requiring the use of named constants instead of built-in numerical constants. He followed the letter, but not the spirit of the law, defining one hundred constants: (Everything is relative. The components on TopCoder have a similar rule, and its letter is more important than the spirit - yes they would be happy to get this programmer - approx. Per.) By the way, a simple redefinition of the constant entertain people trying to accompany your code for a long time.
Have you always wanted to write system level code? This is your chance! Ignore standard libraries and write your own equivalents. It will look amazing on your resume!
Write, for example, your own memory allocator, which will simply allocate memory on the heap. Instead of writing complicated procedures to free up occupied memory, require users to periodically reboot to clear dynamic memory. Once agreed to such a strategy, they will never get rid of it.
(Again, in 1996, the unusual languages were not at all what they are now, so the chapter was reduced to the main idea with a couple of examples - approx. Per.)
Choose a language that is unusual for the companion, and use the features of its syntax to the maximum. In SQL, use single- and two-letter synonyms for tables or the names of other irrelevant tables; if possible, use different syntax options - just to keep others in
good shape. In Visual Basic, declare a variable type a symbol: instead write
Compile the code into an executable file; make sure it works; make a number of small arbitrary changes to the source code, but do not recompile it; leave the modified code in the repository. When the program stops working after the next change, it will seem that the error is in it.
If your employees like to use a line-by-line debugger, place several statements on one line - for example, the if-then-else construct can fit on the whole line.
Often make changes to your code, and require regular updates from the user - you don’t want to use the irrelevant version? Do not tell anyone what the difference is between the versions - they do not need to know about errors that they did not notice themselves.
(A strange tip for repositories that can compare files is approx. Per.)
Do not release versions of programs that only fix errors - be sure to add a few significant changes to the interface, database structure or file format. People who are really bothered by this error will cope with the update, and the rest will get used to and start calling it not a bug, but features. Most likely, compatibility is required from you - well, but provide it in only one direction. Ideally, older versions of the program should not recognize files created in newer versions at all (yes, some word processors provide an excellent example).
The “About the program” window may contain the name of the program, the list of authors, copyright, several megabytes of code that generates an animated picture - but not the version of the program, the date of the last update, or the site from where it can be downloaded. Then everyone will be able to use different versions, report long-fixed errors, etc.
After that, you can write and someone will definitely fix it on. For a change, you can assign TRUE and FALSE the same values. (Yes, yes, I remember #define TRUE (random ()> 0.5) - approx. Per.)
If you write in C ++, pretend that you do not know about STL, and write all operations with arrays and strings manually - this will allow you to maintain your skills in handling pointers, and at the same time prevent any attempts to change the code by outsiders. On the other hand, include third-party libraries in the project - this will allow you to include them in your resume, while remaining unaware of them.
If your compiler has a bug, make sure your code is based on it. Once you use this tool, no one else should look for alternatives.
If your compiler warns about the presence of unused variables, do not delete them, but figure out how to use them. My favorite method is i = i.
The best opportunity to try out these examples on your current program is a week before you quit and move to another country for permanent residence. In other cases, following these tips can be dangerous to your health. The author and translator are not responsible for the harm caused to the national economy and individuals as a result of using the advice of this article.
Testing
If you leave a bug or two in your program, then the person who comes after you will have something to have fun.
1. Do not test error handlers
Never test code that handles any hardware or operating system failures. Anyway, this code is never executed and only delays the development process. Also, how can you check how your code handles disk crashes, file read errors, operating system crashes, and other special situations? After all, for this you will need either an extremely unreliable computer or a sandbox that will simulate it. Modern hardware never fails, and what kind of fool would write code just for testing? No, this is not interesting. If users complain, put the blame on the OS or hardware - why should they know if this is so?
2. Do not do stress testing
If something does not work fast enough, advise the client to buy a more powerful computer. Think yourself, if you do stress testing, you can find a bottleneck, you will have to change the algorithms, or even completely redo the project. Who needs it? In addition, performance problems that arise with the customer will provide you with a free trip to some exotic place - most importantly, keep your passport ready.
(U no, the main thing is that the problem should arise on the Cote d'Azur or in Bali, and not in the Far North or in another Tmutarakan - approx.
3. Do not create test cases
Do not test code coverage or path coverage. Automated testing is for wimps. Find out what functions are responsible for 90% of calls to your code and write tests for them. Most likely, this way you test about 60% of your code and save yourself the remaining 40% of the effort. This will allow you to meet deadlines at the end of the project. By the time someone notices that some additional feature is not working, you’ll already have a trace of it.
4. Testing - for cowards!
Too many programmers are afraid - they are afraid of the boss, clients, mail, lose their jobs or go to court. This fear paralyzes and reduces productivity. Studies have shown that the exclusion of the testing phase allows you to perform work ahead of schedule, which eliminates most of these fears. Therefore, brave programmers do not test: their goal is to write code, and the help system and the technical support department will cope with the correction of errors.
If a person is completely confident in his abilities as a programmer, testing is not necessary. Think about it: it is obvious that testing does not solve any technical problems, no, it is a matter of emotional confidence. It is much more efficient to exclude testing and send programmers to self-esteem raising courses: after all, every change in the code will have to be tested for many years, and it is enough to complete the courses only once. The benefits are obvious and amazing.
5. Verify that only debug mode is running.
Debug mode allows you to execute commands in it that are not part of the main mode. Transfer part of the required logic to debug mode, removing it from the main one. With proper ingenuity, the main version of the code will not even compile.
(By the way, it’s relevant - I stepped on this rake quite recently, although by accident - approx. Per.)
Language selection
(This essay began to be written in 1996, so the exact advice is clearly irrelevant, and very few can follow it; only the main idea is given - approx. Per.)
The general trend in the development of programming languages is to increase the reliability and quality of protection against fools. Therefore, you should not use modern languages: insist on the oldest language that you will only be allowed to (but in which you can still program).
Teamwork
Hell is other people.
In this essay, there are hints on how to infuriate your companion, how to stop your boss’s attempts to get the accompanying code from you and even how to start a universal holivar on the topic of code formatting in the repository. Here are some more tips:
1. The giraffe is big, he knows better
If your boss believes that his twenty-year experience with FORTRAN is great for modern programming, strictly follow his recommendations. As a result, the boss will trust you, your career will benefit from this, and you yourself will learn many new and interesting ways to obfuscate the code.
2. No tech support
Do not answer the phone. Forget emails after assigning them a tracking number.
3. Keep your mouth shut
Never be vigilant in matters like Y2K. If you notice something that sneaks up at a certain moment and destroys life in the western hemisphere, do not discuss this with anyone until the time H (the moment of the event minus 4 years), when it’s time to panic and profit from panic.
(It looks like a catastrophe movie scenario, right? - approx. Per.)
Do not tell friends, acquaintances or other competent people, do not publish anything that might suggest a thought. Send one note (of normal priority) to your superiors to cover your ass. You can add this letter as an attachment to another, important and urgent. After that, you can quit quietly, knowing that at the hour of H they will beg you to return with an astronomical increase in salary.
4. Club "Book of the month"
Choose authors who are too busy writing books to program themselves. Search through local bookstores for books with tons of diagrams and no code examples. Browse through the books you have received and learn a few hundred obscure but beautiful words that you can use to intimidate the insignificants following you. Your code should be impressive. The vast incomprehensible vocabulary makes people think that you are very smart and your algorithms are very complex. For completeness, avoid the banal analogies in the explanations.
5. Pretend to be a genius
Geniuses are not too worried about whether their average colleagues keep up with them (and some also experience sadistic pleasure from their suffering), and thus often lead their project to death. Behave even if you are not a genius. At least tell everyone that if they were smart enough, they would have no problem understanding your ingenious code.
6. Pretend to be an idiot
(It contradicts the previous point, but it’s much simpler - approx. Per.)
One C programmer was annoyed by a company policy requiring the use of named constants instead of built-in numerical constants. He followed the letter, but not the spirit of the law, defining one hundred constants: (Everything is relative. The components on TopCoder have a similar rule, and its letter is more important than the spirit - yes they would be happy to get this programmer - approx. Per.) By the way, a simple redefinition of the constant entertain people trying to accompany your code for a long time.
#define ONE 1
#define TWO 2
#define THREE 3
:#define THOUSAND 9997. Self-roll
Have you always wanted to write system level code? This is your chance! Ignore standard libraries and write your own equivalents. It will look amazing on your resume!
Write, for example, your own memory allocator, which will simply allocate memory on the heap. Instead of writing complicated procedures to free up occupied memory, require users to periodically reboot to clear dynamic memory. Once agreed to such a strategy, they will never get rid of it.
Receptions for Unusual Languages
(Again, in 1996, the unusual languages were not at all what they are now, so the chapter was reduced to the main idea with a couple of examples - approx. Per.)
Choose a language that is unusual for the companion, and use the features of its syntax to the maximum. In SQL, use single- and two-letter synonyms for tables or the names of other irrelevant tables; if possible, use different syntax options - just to keep others in
good shape. In Visual Basic, declare a variable type a symbol: instead write
dim Color_var as string
dim counter as integerDim Color_var$, counter%Miscellaneous
1. Do not compile
Compile the code into an executable file; make sure it works; make a number of small arbitrary changes to the source code, but do not recompile it; leave the modified code in the repository. When the program stops working after the next change, it will seem that the error is in it.
2. Interfere with debugging
If your employees like to use a line-by-line debugger, place several statements on one line - for example, the if-then-else construct can fit on the whole line.
3. Improve yourself
Often make changes to your code, and require regular updates from the user - you don’t want to use the irrelevant version? Do not tell anyone what the difference is between the versions - they do not need to know about errors that they did not notice themselves.
(A strange tip for repositories that can compare files is approx. Per.)
Do not release versions of programs that only fix errors - be sure to add a few significant changes to the interface, database structure or file format. People who are really bothered by this error will cope with the update, and the rest will get used to and start calling it not a bug, but features. Most likely, compatibility is required from you - well, but provide it in only one direction. Ideally, older versions of the program should not recognize files created in newer versions at all (yes, some word processors provide an excellent example).
4. “About the program”
The “About the program” window may contain the name of the program, the list of authors, copyright, several megabytes of code that generates an animated picture - but not the version of the program, the date of the last update, or the site from where it can be downloaded. Then everyone will be able to use different versions, report long-fixed errors, etc.
5. Override TRUE and FALSE
#define TRUE 0
#define FALSE 1After that, you can write and someone will definitely fix it on. For a change, you can assign TRUE and FALSE the same values. (Yes, yes, I remember #define TRUE (random ()> 0.5) - approx. Per.)
if ( var == TRUE )
if ( var != FALSE )if ( var )
if ( !var )6. Avoid libraries
If you write in C ++, pretend that you do not know about STL, and write all operations with arrays and strings manually - this will allow you to maintain your skills in handling pointers, and at the same time prevent any attempts to change the code by outsiders. On the other hand, include third-party libraries in the project - this will allow you to include them in your resume, while remaining unaware of them.
7. Compiler dependent code
If your compiler has a bug, make sure your code is based on it. Once you use this tool, no one else should look for alternatives.
8. Unused variables
If your compiler warns about the presence of unused variables, do not delete them, but figure out how to use them. My favorite method is i = i.
Translator's epilogue
The best opportunity to try out these examples on your current program is a week before you quit and move to another country for permanent residence. In other cases, following these tips can be dangerous to your health. The author and translator are not responsible for the harm caused to the national economy and individuals as a result of using the advice of this article.