Clean Code, who missed the p(o)int... ?
-
Clean Code: I like it, at least parts of it. But now I just recognized that some co workers interprets this, that it is enough having their code clean formatted text whise (indentation etc.) Can be that I'm wrong, but I think they have missed the point :(
People following the form because they don't bother understanding the content ain't news, sadly.
-
Marc Clifton wrote:
Unfortunately much of our field is littered with terms like "clean code", "Agile", "SOLID"
And "readability".
Marc Clifton wrote:
I still have no idea who the heck Liskov is/was.
I looked for actual studies on "readability" at one time. There must be some given how much developers use that term to justify almost anything. There was one study that involved fonts used in marketing materials (and it was probably printed marketing also.) As I recall the conclusion was that 4 or fewer fonts should be used. Nothing else.
Most readability responses are along the lines of: - "They don't RTFM, so why write a good one", - "Comments in code is bad", - "I'm not good at (variable) naming". Nothing to read. Unplanned code obsolescence! Thank goodness(?) for Emoji's.
-
If they mid level plus, then just share out this summary, which is nice quick scan over. Just helped me when I was trying to recall what clean code is. [Summary of 'Clean code' by Robert C. Martin · GitHub](https://gist.github.com/wojteklu/73c6914cc446146b8b533c0988cf8d29)
I've never read it, but that's a really good summary, though there are a few terms that need explaining.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
People following the form because they don't bother understanding the content ain't news, sadly.
It's called Cargo Cult [whatever]. :-\
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
-
Most readability responses are along the lines of: - "They don't RTFM, so why write a good one", - "Comments in code is bad", - "I'm not good at (variable) naming". Nothing to read. Unplanned code obsolescence! Thank goodness(?) for Emoji's.
PhilipOakley wrote:
Thank goodness(?) for Emoji's
Especially this one: 💩
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
-
Marc Clifton wrote:
Unfortunately much of our field is littered with terms like "clean code", "Agile", "SOLID"
And "readability".
Marc Clifton wrote:
I still have no idea who the heck Liskov is/was.
I looked for actual studies on "readability" at one time. There must be some given how much developers use that term to justify almost anything. There was one study that involved fonts used in marketing materials (and it was probably printed marketing also.) As I recall the conclusion was that 4 or fewer fonts should be used. Nothing else.
I have one person in my team who will insist on doing things their way, because of clean code and readability. It's such a moot point, IMHO. Practically speaking, you should stick to the following: Structurally, you should keep the cyclometric complexity low --> you'll have cheaper A/B testing in the future, which is a good fallback strategy for unforeseen issues of all sizes. Syntax wise, just copy whatever style is prevalent in the code-base already, and reduce inconsistencies --> cheaper refactoring in the future. Quality wise, you should always aim for less lines of code, without resorting to ANY advanced language techniques --> less reading to understand the code, less esoteric bugs. Just do those three things to drive costs down and quality up. Everything else is pointless. The compiler doesn't care about the look and feel of the code and the user definitely doesn't care. We should take a hint and stop caring so much too.
-
It's called Cargo Cult [whatever]. :-\
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
Right, thank you!
-
I have one person in my team who will insist on doing things their way, because of clean code and readability. It's such a moot point, IMHO. Practically speaking, you should stick to the following: Structurally, you should keep the cyclometric complexity low --> you'll have cheaper A/B testing in the future, which is a good fallback strategy for unforeseen issues of all sizes. Syntax wise, just copy whatever style is prevalent in the code-base already, and reduce inconsistencies --> cheaper refactoring in the future. Quality wise, you should always aim for less lines of code, without resorting to ANY advanced language techniques --> less reading to understand the code, less esoteric bugs. Just do those three things to drive costs down and quality up. Everything else is pointless. The compiler doesn't care about the look and feel of the code and the user definitely doesn't care. We should take a hint and stop caring so much too.
Programmers who can't be bothered to use linting tools are rarely concerned with cyclometric complexity, or maintenance cost, or refactoring. Also, it seems the broken window theory applies to software: if it's already crap software, most people won't bother with writing good code, resorting instead to the metric of lowest cost to write (even if it means the user or company pays the price many times over).
-
Readability is actually really important. The reason you can't find studies on it is that it varies by language, norms, code history, etc. I mean, sure, there are *some things* that are simply unreadable no matter what, but most often readability is highly subjective and team-based. Making hard and fast rules about it is very impractical and verging - in my opinion - on impossible.
DeerBear wrote:
The reason you can't find studies on it is that it varies by language, norms, code history, etc.
Nope. The reason you can't find any studies on it is because one needs to first be able to measure something to do a study. You can't declare that something is 'better' if you cannot define how to measure that it is so. Would you sign a contract that said your code must be 'better' or you don't get paid unless the contract specifically stated how that would be measured?
-
Programmers who can't be bothered to use linting tools are rarely concerned with cyclometric complexity, or maintenance cost, or refactoring. Also, it seems the broken window theory applies to software: if it's already crap software, most people won't bother with writing good code, resorting instead to the metric of lowest cost to write (even if it means the user or company pays the price many times over).
Andre_Prellwitz wrote:
bothered to use linting tools are
Sigh... Static checkers are useless. They were useless 40 years ago when I first saw them and just as useless now. I have seen a static checked which tagged switch statements as being too complex. The 'solution' which some programmer implemented to fix that and which was reviewed and passed involved creating 40 objects every single time. 40 objects that could not even be created successfully every time. That code ended up in production. So it went from a very valid and correct idiom to one that failed. If the teams consists of NOTHING but junior developers then maybe they might provide a benefit. But if there is even one mid level developer and that person actually takes code review seriously then that is going to be far more effective.
-
Andre_Prellwitz wrote:
bothered to use linting tools are
Sigh... Static checkers are useless. They were useless 40 years ago when I first saw them and just as useless now. I have seen a static checked which tagged switch statements as being too complex. The 'solution' which some programmer implemented to fix that and which was reviewed and passed involved creating 40 objects every single time. 40 objects that could not even be created successfully every time. That code ended up in production. So it went from a very valid and correct idiom to one that failed. If the teams consists of NOTHING but junior developers then maybe they might provide a benefit. But if there is even one mid level developer and that person actually takes code review seriously then that is going to be far more effective.
Agreed, static code analysis is designed to provide false positives over false negatives. What I actually meant was the simple linters that fix code style differences; if you cannot even agree on standards (rules such as "interface names should start with the letter 'I'", or "avoid Hungarian notation") then what are the odds you can agree on what's considered "clean"?
