Clean Code, who missed the p(o)int... ?
-
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"?