Why do programmers like to stick to "Thou shalt" / "Thou shalt not" rules that define whether a code is of good or bad quality?

Question

I'm not sure how to correctly describe my problem...

Ever since I started learning how to program, I recognized that many more experienced programmers have very strict (and, in the POV of a beginner, completely artificial) rules how should programs be written. These rules seem simplicistic, yet are followed with an almost religious zealotry.

Examples of such rules:

• Thou Shalt Never Use Goto Unless Thou Writest Thine Programs In The Assembly Language;
• Thou Shalt Never Use #regions;
• Thou Shalt Never Use Properties;
• Thou Shalt Never Use Global Variables;
• Thou Shalt Use Dependency Injection Instead Of Calls To Static Methods Or Members;
• Thou Shalt Never Use Protected Fields;
• Thou Shalt Always Abide By Uncle Bob's Prescriptions;
• Thou Shalt Always Abide By Martin Fowler's Prescriptions;
• If Thou Thinkest Thou Needest To Break These Rules Thou Hast Designed Thy Architecture Wrongly And Oughtest To Redesign And Refactor Thy Code Until Thou No Longer Needest To Break These Rules.

Sometimes we can see some programmers following mutually exclusive "Thou Shalt" rules; then an almost religious discussion is likely to start whose rules are the correct ones.

Problem is, I've always had problems with following such rules or listening to people who look at my code and exclaim, "You Are Doing X But It Is Evil To Do X Refactor This According To My Arbitrary Prescriptions Or I Judge Your Code To Be Of Bad Quality Even Though It Works Flawlessly". (This is, at least, how such people's arguments were sounding in my ears.)

I must say I have an intellectual gag reflex when I see such a keen use of the universal quantification ("Thou Shalt Always / Never"). I am also perplexed when I see programers the more happy the more restrictions are placed upon them, for example when a programming language decides not to support a feature they perceive as "Evil" or when their project adopts a new, stricter code quality policy, outright rejecting any piece of code that uses X (or doesn't use X), regadless of context.

It has been my personality trait since childhood that I was more than inclined to disregard requirements I'm perceiving as arbitrary or pointless. When put in the context of programming, this means I was eager to get myself into arguments with people who were considering my code to be of a bad quality because it was violating some of such rules. I was getting annoyed when I was hearing arguments like "Since you're not as experienced as we are, you should be learning rather than contesting something you don't even understand" or "Read 'Clean Code' by Robert C. Martin" or "The law doesn't require everyone to be a good coder, if you want to be a bad one, you are free to do it - but please, make sure I don't have to read this abomination you call 'code' you're writing ever again". On the other hand, when people were actually using substantitive arguments, I was usually rejecting them as long as I couldn't verify them; and I could never verify such requirements like "Thou Shalt Not Use Global Variables", maybe because I've never written code large enough for this to be an issue.

I've once browsed to a random source file of the Linux Kernel. I laughed when I saw it breaking many of these "Thou Shalt" recommendations. Longish functions? Gotos? Global variables? Self-modifying code? If these zealots were right, the Linux Kernel could have never be that successfull for such a long time with all of those "anti-patterns"!

Finally, I've always had an intellectual gag approach when I was seeing newbie programmers (like me) eager to listen to such rules, remember them, religiously follow them, and repeat them, and teach them to everyone. Quite often, they were doing this without understanding these rules (more than I was understanding), so in my eyes they were... trying to seem more Wise, or Advanced than the rest of us newbs, because they repeat what more experienced programmers are saying, even though they clearly don't understand it. I was seeing them as... hatchlings, who collect feathers of a rooster and glue them to their rumps, and then they walk pridefully among other hatchlings, doing their best to mimic a rooster's moves, as if they were trying to say: "See? I'm almost a rooster!" (I've had similar reactions when I was seeing my peers condemn Microsoft and praise Linux and Google instead - I was thinking, "Ha, they see geeks don't like Microsoft, so these wanna-be geeks must not like Microsoft as well, of couse!")

Well, now I'm seriously thinking if I didn't harm myself by this approach - because indeed, I may have prevented myself from learning, by refusing to accept that even if I don't understand that X is a good or bad thing, this still doesn't stop X from being a good or bad thing!

I wonder... what should be the standard response to those like me?

Answer 1

On the other hand, when people were actually using substantitive arguments, I was usually rejecting them as long as I couldn't verify them; and I could never verify such requirements like "Thou Shalt Not Use Global Variables", maybe because I've never written code large enough for this to be an issue.

(Emphasis mine)

Writing code is a new phenomena in human culture. It is not part of our DNA, so there is no reason to think that your intuitions about how code should be structured are particularly useful. As you admit, you haven't written any large coding projects, so you're in Dunning-Kruger territory. Most of the "rules" are in service of avoiding common errors and writing code that can be read and comprehended by other programmers. Until you start writing larger programs, and in particular, until you start writing programs in active collaboration with a team of programmers, the rules may seem pointless. Just keep in mind that your experience is limited at this stage.

I was seeing them as... hatchlings, who collect feathers of a rooster and glue them to their rumps, and then they walk pridefully among other hatchlings,

Apparently you are also being distracted from thinking critically about coding "rules" by your fears about your rank in the coding pecking order. This might be pragmatic when it comes to politics on the job, but it isn't useful in learning how to code. Let go of your ego. This becomes easier as you get more experience. You'll have less time to grouse about your colleague's code because you'll be too busy fixing the ignorant and careless code you wrote two year ago.

My advice is to start by assuming that your own ignorance is vast, that other people are not idiots, and they are generally acting with good will. You may have to reappraise matters later on, but that's where to start.

I do agree that presenting these principles as absolute rules is a mistake, and you are absolutely justified in asking for an explanation of their foundations. However, if the explanation doesn't make sense to you, be open to the idea that it doesn't make sense because of the limitations of your own experience, not because the guideline is total BS. Often they are only partially BS.

I've once browsed to a random source file of the Linux Kernel. I laughed when I saw it breaking many of these "Thou Shalt" recommendations.

Did you actually understand the code you read or did you just scan it for global variables and long functions? OS kernel code has some very strong and unusual constraints compared to other types of software projects. Speed, speed, speed, and the handling of absolutely all possible error conditions are the driving factors. Readability by other (non-kernel) coders is way down on the list of of requirements for good kernel code.

Answer 2

Problem is, I've always had problems with following such rules or listening to people who look at my code and exclaim, "You Are Doing X But It Is Evil To Do X Refactor This According To My Arbitrary Prescriptions Or I Judge Your Code To Be Of Bad Quality Even Though It Works Flawlessly". (This is, at least, how such people's arguments were sounding in my ears.)

These are the words of a coder who only respects the CPU's opinion of his code. It compiles. It runs. It has no bugs. So I'm done. Stop talking to me about it.

Sigh, well sure, that's fine when you own the code. If no one else has to look at it, why should you care? But if someone is telling you X is Evil then someone is looking at your code. That means the CPU isn't your only audience. And if that's the case it is flat out unprofessional to not consider their advice.

Coding is about humans. I know. It sucks. I didn't get into this field because I loved dealing with people. I love dealing with things. But you have a responsibility to consider how human friendly your code is.

When you write something you understand it because it does what you wanted it to do. When you read it you remember what you wanted it to do and it's no surprise when it does that. That's great but it means the greatest authority on the readability of your code is anyone but you.

So you have to show your code to other people. You have to listen to them. Even when they're wrong and stupid. What you need to do is learn how to address their concerns. That means you have to know what they're talking about. You have to know when it's applicable and when it's not. You have to be able to explain, convincingly, why it's ok to do X in your case even though many sources say X is wrong.

You also have to be willing to learn something. To stop doing X when it turns out you were wrong. Sure the CPU was happy but you can now see that you were going to cause problems. Maybe because it was going to make the code rigid making it hard to add new features. Maybe because it was going against the established coding style. Maybe because you're so smart that these newbs they keep hiring can't keep up with your 1337 skills. Whatever the reason, you have to consider more than the CPU. You also have to keep the humans happy.

If you're so smart then you also have to be willing to teach something. If I'm whining about X and you just ignore me then you'll be dealing with X the next time you maintain my code. If my X issue is time wasting nonsense then you owe it to me, the company, and to yourself to understand X well enough to explain to me why it's not applicable here. Do it sooner rather than later. I'm less stubborn before I write the code. Again, keep the humans happy.

This is life on a software team. You don't get to hide in a hole for 6 months and emerge with golden code ready to move on to the next job. You have to work with people.

I know. It sucks. But that's the job.

Answer 3

Great programmers are not always great teachers.

Complex lessons are hard to learn.

We know that global variables for example can cause various problems. But to enumerate and go into them all and why each can trace its root to the use of global variables would be a long and boring series of lectures, which would be hard for the teacher to give and hard the student to understand.

Hence the rule. The rule is easy to understand and to follow. Maybe the rule is too general and thus wrong for some situations, but its something you can follow without understanding the why.

If you want to understand the whys then yes, breaking the rules us a good idea.

If you are new and want to avoid the mistakes of the past without studying them all in detail. Follow the rule

Answer 4

Rather than seeing these rules as restrictions consider them as advice.

As for Martin Fowlers work, if you're talking of Refactoring then it is frankly self-evident as to why the codes improved.

Regarding Uncle Bob, albeit more abstract he goes into great detail with examples justifying his advice, he didn't write books centered on 'arbitary' rules.

I know some coders hate books these days but they are great for a getting a deeper understanding. Instead of rejecting this stuff outright because some newbie was parroting it, or following it blindly go to the source material and judge for yourself.

Answer 5

Let's make a shift in perspective.

The question is not:

Why do programmers like to stick to “Thou shalt” / “Thou shalt not” rules that define whether a code is of good or bad quality?

The question - in a general sense - is:

Why do people stick to rules - and sometimes even though the context where those rules made sense is not or no longer relevant?

This kind of behaviour is not limited to programmers, it is more about people in general.

On the one hand there is the practical knowledge of how to do things.

On the other hand you have the aspects of:

I) The right way

Doing things the right way implies making you better than others.

Think of discussions about ideomatic code. This is clearly not about (non) working code, but doing things in the right way.

II) The shared way

A group of people doing things in a common way shared by the group strengthens the group from the inside, and also helps distinguishing from others on the outside: doing things in a certain way is an indicator, that you belong to a certain group. Think of using Hungarian Notation. There is nothing wrong even in say Python of naming your Variables szFirstName. But doing so, you show clearly, that you do not know the shared rites of writing ideomatic code and show, that you are an outsider. Or god forbid doing for i in range(len(word)), which is working, but very nonideomatic Python.

III) Argumentum ab auctoritatem

"Martin Fowler said...", "Robert C Martin said ...", "Kent Beck said ..."

As everywhere this kind of forcing people's behaviour in some direction with accepted authorities has no exception in IT. And questioning authorities is risky, even in IT.

This is no special behaviour limited to IT. It is how many people work.

Why do people work this way?

Because it makes life easier:

• You are socially accepted (liked) by your peers.
• It helps you defining your identity: You are doing things the right way not like those "others" doing it wrong (the whole day)
• If you do it like everyone else and like last year, you save energy for other tasks

---

In general it is very hard to reason about code. I would like to think it being as hard as reasoning of writing a good novel. There are inherent metrics: Code works or it doesn't. But that says nothing about the quality.

Unfortunately bad code runs not necessary worse than good code - but admittedly imperformant code is oftentimes an indicator for bad code, because oftentimes people who do not care about style do not care about performance either. Sometimes even the opposite might be true: The bad code performs better than a more beautiful version.

Last but not least, some "rules" orignated in a certain context, where it made totally sense and helped to avoid a lot of problems, but that does not make it a commandment.

I oftentimes myself realize, seeing something like Law of Demeter as a law and not as a recommendation.

These rules are like support wheels, helping learning to ride the bike.