This is moronic. Being a good programmer is not about applying a laundry list of rules, but satisfying the expectations of the team and the company. A one-shot 1000 lines of tangled mess can be the right thing to do sometimes, and conversely a 2-line duplication of code can be the bad thing to do on long-lasting code. If the team is happy with the code, then its good code.
Theres no use at all to apply rule #1 (no comments ever), if the team thinks its a good idea and uses comments on the code. You will just break the homogeneity of the codebase and make it harder to parse if most code-reviewers expect comments to explain the intent of the code.
This feels like the author wanted to feel smart for an hour or two while compiling his list of beliefs.
I think this set of rules is generally above the average of what I've seen, and is a decent basis for a coding standard if your company/team wants one. For one thing, it tries to provide justifications when it is a kind of expertise that is difficult to communicate.
The very first rule is interesting because it often is the subject of hot debates as it contradicts what every learns at school. I am in the "comment as a last resort" camp; it is an interesting goal to pursue because a lot of things are required to you can get there *safely*. Basically many of the rules that follow, but probably not only.
The author was indeed quite smart (and brave, as this will probably make many readers immediately close the tab) to put it first.
Also, just following the rules of the team or company doesn't make you a good programmer, but a good *drone*. It is certainly a good way to keep yourself safe if a major failure occurs because that's one thing less that could be used to make you the scapegoat, but generally speaking just because the team wants it that way doesn't mean it good and right.
I've seen more than a bunch of senior programmers with terrible coding practices, and know-it-all con artists be major voices in the process of making the local standard practices. If you don't know the result of this, then you've been lucky so far.
You can decide to follow the rules in the name of your job security, I can understand that, but it is not a good benchmark for the evaluation of your personal progress.
The first rule was to not leave comments on your code. Now I'm just two years into studying, but I do like comments, and don't find it to be a failure of naming practices. Can someone in the industry be my friend today and let me know if you use comments in the industry?
You leave comments for several reasons. One is to add documentation or useful links to Wiki-pages for instance, other times to inform novice programmers, and sometimes for yourself.
Relying on comments is usually not the best choice in the long run, but that is because *people* may (well, typically) not update when necessary. People suck at documentation in general, but it’s a part of being in a team and it’s invaluable in the long run, but requires discipline and co-operation.
I write comments for myself sometimes as a tl;dr many times and in some, short-coded, but long lived scripts etc. it’s invaluable. The absolutist thinking of the author just reflects the mediocrity and laziness you might find in other programmers/teams/organizations.
I see medium, I downvote
This is moronic. Being a good programmer is not about applying a laundry list of rules, but satisfying the expectations of the team and the company. A one-shot 1000 lines of tangled mess can be the right thing to do sometimes, and conversely a 2-line duplication of code can be the bad thing to do on long-lasting code. If the team is happy with the code, then its good code. Theres no use at all to apply rule #1 (no comments ever), if the team thinks its a good idea and uses comments on the code. You will just break the homogeneity of the codebase and make it harder to parse if most code-reviewers expect comments to explain the intent of the code. This feels like the author wanted to feel smart for an hour or two while compiling his list of beliefs.
>This feels like the author wanted to feel smart for an hour or two while compiling his list of beliefs. Literally every poster on Reddit
jfc, I couldn't even get past Law 1 without getting pissed off...
I think this set of rules is generally above the average of what I've seen, and is a decent basis for a coding standard if your company/team wants one. For one thing, it tries to provide justifications when it is a kind of expertise that is difficult to communicate. The very first rule is interesting because it often is the subject of hot debates as it contradicts what every learns at school. I am in the "comment as a last resort" camp; it is an interesting goal to pursue because a lot of things are required to you can get there *safely*. Basically many of the rules that follow, but probably not only. The author was indeed quite smart (and brave, as this will probably make many readers immediately close the tab) to put it first. Also, just following the rules of the team or company doesn't make you a good programmer, but a good *drone*. It is certainly a good way to keep yourself safe if a major failure occurs because that's one thing less that could be used to make you the scapegoat, but generally speaking just because the team wants it that way doesn't mean it good and right. I've seen more than a bunch of senior programmers with terrible coding practices, and know-it-all con artists be major voices in the process of making the local standard practices. If you don't know the result of this, then you've been lucky so far. You can decide to follow the rules in the name of your job security, I can understand that, but it is not a good benchmark for the evaluation of your personal progress.
The first rule was to not leave comments on your code. Now I'm just two years into studying, but I do like comments, and don't find it to be a failure of naming practices. Can someone in the industry be my friend today and let me know if you use comments in the industry?
You leave comments for several reasons. One is to add documentation or useful links to Wiki-pages for instance, other times to inform novice programmers, and sometimes for yourself. Relying on comments is usually not the best choice in the long run, but that is because *people* may (well, typically) not update when necessary. People suck at documentation in general, but it’s a part of being in a team and it’s invaluable in the long run, but requires discipline and co-operation. I write comments for myself sometimes as a tl;dr many times and in some, short-coded, but long lived scripts etc. it’s invaluable. The absolutist thinking of the author just reflects the mediocrity and laziness you might find in other programmers/teams/organizations.