-4

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:

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?

closed as primarily opinion-based by gnat, Nicol Bolas, kevin cline, Jörg W Mittag, Doc Brown Jun 3 '18 at 14:01

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 3
    Many of the guidelines, or “rules”, you reference guide the developer in creating optimally maintainable and reusable code. GOTOs and global variables make both of those goals difficult to attain. There are times that a developer must sacrifice those goals in lieu of performance, but in general, we strive to make our code as maintainable and reusable as possible. There is nothing wrong with learning through reinventing the wheel. However, you should curb your arrogance and at least respect the advice of more experienced developers. We see much further when standing on the shoulders of giants. – Joshua Jones Jun 2 '18 at 17:33
  • 3
    @gaazkam: Where exactly are these rules coming from? That is, you've assembled a list of general prohibitions, but at no point do any of your links support the notion that these are the divine commandments you seem to present them as. – Nicol Bolas Jun 2 '18 at 18:40
  • 3
    @gaazkam: "when someone says: "Is there a good use for regions? No." (emphasis original)" But he didn't just say that. He explained in meticulous detail why he feels that way. You don't agree; that's fine, I guess. But since you are a self-admitted novice and the person you're talking to is decidedly not a novice, why don't you consider the possibility that dismissing his explanation is perhaps not the right thing to be doing? – Nicol Bolas Jun 2 '18 at 20:03
  • 2
    "what should be the standard response to those like me?" - ask "why?" to the person telling you, and then thank them for explaining it to you. – Bryan Oakley Jun 2 '18 at 21:11
  • 4
    I would honestly love to hear what the OP thinks of this post in five years. – James McLeod Jun 3 '18 at 13:32
11

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.

  • "Code is not part of our DNA." Made me laugh because DNA is code. :) – candied_orange Jun 2 '18 at 18:17
  • 5
    @candied_orange "DNA is code" , actually DNA is an incredibly complex macromolecule, that can in certain circumstances be usefully abstracted as a string of symbols from a four letter alphabet. Yes, I saw the smiley, but I work in bioinformatics, this is a particular peeve of mine, and I'm a humorless prig. – Charles E. Grant Jun 2 '18 at 18:21
  • 2
    @CharlesE.Grant: "I do agree that presenting these principles as absolute rules is a mistake" I disagree. For an audience consisting of novice programmers, general prohibition of bad ideas is a good thing. Yes, there are corner cases where these things can be the least-bad answer to a problem. But novices are not going to be "novices" when they encounter such things. It's a lot easier to internalize "don't use goto" than "avoid goto unless you're deeply nested in some conditional loop hell and cannot reasonably structure your way out of it." – Nicol Bolas Jun 2 '18 at 18:48
  • 2
    @CharlesE.Grant: Teaching is as much about what you don't say as what you do. Take goto, for example. Spending time showing circumstances where it is legitimate to use goto takes time away from getting on with the 10,000 other things that novice programmers need to learn. Such discussions rarely lead into any future lessons, since novice lessons and assignments won't require the kind of Gordian-knot code that naturally leads to goto usage. Such discussions just take up space in the middle of a lesson. And if you're not reinforcing a lesson, then it isn't being learned. – Nicol Bolas Jun 2 '18 at 20:11
  • 1
    Excellent point about kernel code being an exception to many rules in the interest of speed and robustness. – Bryan Oakley Jun 2 '18 at 21:13
8

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.

6

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

  • 2
    You were doing great until you said "Breaking the rules us (sic) a good idea." The right answer is to go back and read the papers that were written at the time about WHY e.g. goto and global variables are generally considered Bad Ideas. – John R. Strohm Jun 2 '18 at 16:33
  • 6
    History is great, but some people (and I think the OP is in this category) learn by doing. – Ewan Jun 2 '18 at 16:39
  • 3
    I don't know any company that can afford to let someone learn well over fifty years of computing lessons by making all the same mistakes on company time and equipment. Do you also advocate that people learn that drunk driving is a bad idea by pouring themselves full off rotgut and then going out and driving? – John R. Strohm Jun 2 '18 at 16:43
  • @JohnRStrohm No of course not! but if you read gaazkams other question he is a student working on his own time – Ewan Jun 2 '18 at 16:45
  • 2
    @Ewan remember the op isn't the only one learning from your answer. Take a moment to establish the context of the advice so this can help others as well. – candied_orange Jun 2 '18 at 18:14
0

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.

-3

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.

  • 3
    Dunno about the other downvote, but it earned mine due to condescending tone and bad advice. The rules in the question are hardly "cargo cult programming", and I really don't want to end being the guy who has to deal with the code review fights it'll take to unteach the goto/null/unmockable global calls/etc use that this answer implicitly endorses. They cause real problems in modern code, not just in the context of the writing of seminal (but ancient feeling) papers like "GOTO considered harmful". – Morgen Jun 2 '18 at 22:19
  • 3
    If you want feedback, I'd suggest dropping the condescending scare quotes. That tone is a big part of the problems with this answer. The whole thing paints guidelines that have become industry touchstones (and with good reason) as the outdated zealotry of inferior programmers. This is bad advice to anyone, and doubly dangerous when given to a student. It's akin to telling someone "always treat a gun as if it were loaded" is a guideline from a time when guns weren't as well made, and can be ignored once you've learned to use it. – Morgen Jun 3 '18 at 0:29
  • 1
    I think the point of the question is not: why is there such and such rule? Is it good or is it bad? The question is more: why do people treat me like that? And the answer to that is: because they behave like people and do things like e. g. building groups, developing rites etc. And as in every group: not playing by the rules gives you a hard time. – Thomas Junk Jun 3 '18 at 8:01
  • 1
    @ThomasJunk: "I questioned the non technical motives of people giving advice to e.g. students." That's kind of the point: what makes you say that there are "non technical motives"? Or that such motives are at all significant next to the technical ones? Your post ignores any technical merit and therefore by implication suggests that there is no technical merit, that they're there solely to "build groups, develop rites etc". That's like telling an architect that the rules they use to design buildings are just about group dynamics, not about keeping buildings from collapsing. – Nicol Bolas Jun 3 '18 at 15:49
  • 2
    @ThomasJunk as the only rules on the OP's list that really align with that are the references to Uncle Bob & Martin Fowler, it would vastly improve your answer to start by explaining you're addressing a specific part of the question, include specific examples, and guidelines for identifying misapplied rules. A student is highly unlikely to be able to make that determination without some guidance. For example, nulls are safe to use in SQL because they behave less like classic nulls and more like a monadic option type (ex: Java 8 Optional). As it is, your answer ends up less honest by omission. – Morgen Jun 3 '18 at 17:30

Not the answer you're looking for? Browse other questions tagged or ask your own question.