We all made it: grab a cookie when Mama was not looking, drank a bit too much wine for dinner and left the car in a parking lot after the meter ran out.
We even walked around Deadman’s bend a bit too fast. And yes, we’ve all violated any number of key programming rules. Those who all agree are bad. And we secretly liked it.
We have come to terms with the rules of good programming, written code that is totally bad – and we have lived. There were no flashes from the programming gods. Our desktops have not exploded. Our code was compiled and shipped, and customers seemed satisfied.
This is because poor programming is not in the same league as licking an electric fence or pulling a tiger’s tail. Mostly it works. The rules are more common guidelines or stylistic suggestions, not directives that must be obeyed, or the code death will follow. Sure, your code could be ridiculed, possibly even public. The fact that you oppose conventions adds a little to the thrill, even if you accidentally undermine what (usually) corresponds to the social customs of a pleasant code.
Sometimes, for reasons of complexity, it is better to break the rules. (Shhhh!) The code comes out cleaner. It can even be faster and easier. The rules are usually a bit too broad, and a skilled programmer can improve the code by breaking it. Do not tell your boss, but sometimes it makes sense to code your own way.
What follows is a list of nine rules that some consider to be unassailable, but many of us break frequently, both with success and pleasure.
Bad Programming Habit # 1: Copy
It is wrong to do this at school. At work, the rules are not so clear. There are certainly some code blocks that should not be stolen. If it’s proprietary code, do not fold it into your stack, especially if it’s marked with a copyright notice. Write your own version. You will be paid for it.
The more difficult question comes when the original creator wants to share. Maybe it’s in one of these online program forums. Maybe it’s open source code with a license (BSD, MIT) that allows you to use one or three functions. There is no legal reason to stop you. And you are paid to solve problems and not reinvent the wheel.
Mostly the advantages of copying are convincing and the disadvantages can be limited with a little care. At least one train of thought has been applied to the code you receive from a reputable source.
The original author sought a solution and found something. The loop invariants and the data flow have been worked out.
The tricky questions are whether there are some undetected errors or other assumptions about the role or the underlying data.
Maybe your code mixes in null pointers, while the original code never checked them. If you can fix the issues, your boss seems to be supported by two programmers. It’s a couple programming without the chic desks.
Bad Programming Habit # 2: Non-working code
In den letzten zehn Jahren ist das Funktionsparadigma aufgestiegen.
Die Experten für die Erstellung Ihres Programms aus verschachtelten Funktionen zitieren gerne Studien, die zeigen, wie sicherer und fehlerfreier der Code ist als die älteren Variablen- und Schleifenstile, die auf jede Art und Weise aneinandergereiht sind, die den Programmierer glücklich machen.
Die Anhänger sprechen mit dem Eifer der wahren Gläubigen und verurteilen in Code-Überprüfungen und Pull-Anfragen nicht-funktionale Ansätze. Sie haben vielleicht sogar Recht mit den Vorteilen.
Aber manchmal muss man nur eine Rolle Klebeband herausholen. Wunderbar entwickelter und elegant geplanter Code braucht Zeit, nicht nur um sich etwas vorzustellen, sondern auch um ihn zu konstruieren und später zu navigieren. Alle diese Schichten erhöhen die Komplexität, und Komplexität ist teuer.
Entwickler von schönem funktionalem Code müssen vorausplanen und sicherstellen, dass alle Daten auf geeigneten Wegen weitergeleitet werden. Manchmal ist es einfacher, eine Variable zu erreichen und zu ändern.
Vielleicht schreibe einen Kommentar, um es zu erklären. Sogar das Hinzufügen einer langen, krassen Entschuldigung zu zukünftigen Generationen im Kommentar ist schneller als das Neuarchitekturen des gesamten Systems, um es richtig zu machen.
Schlechte Programmiergewohnheit Nr. 3: Nicht standardmäßiger Abstand
Die meisten Leerzeichen in der Software wirken sich nicht auf die Leistung des Programms aus.
Abgesehen von einigen Sprachen wie Python, die den Abstand zur Angabe von Codeblöcken verwenden, haben die meisten Leerzeichen keine Auswirkung auf das Verhalten des Programms.
Even so, there are obsessive programmers who count them and insist they are important. One of them once told my boss in the most serious tone that I write „Non Standard Code“ and he can see it immediately. My sin? ESLint Space Infix Ops Rule violations by not inserting spaces on either side of an equals sign.
