4 ms·
> about how a code base "is crap" Translation: "Not written in the particular arbitrary style that I'm used to", of course if it were written in that persons p
by nullc 6y ago
> about how a code base "is crap"
Translation: "Not written in the particular arbitrary style that I'm used to", of course if it were written in that persons preferred style another arbitrarily selected novice would call the result crap.
I've found this to be almost universally true especially when the claim is given forcefully but not immediately backed up with a litany of actual user-impacting serious problems.
This is not to say that code can't be crap, but generally people with the wisdom needed to make that determination know better than to waste their time yelling about it and know enough to suggest how to make it better instead. They recognize that good code can be written in a multitude of styles and that there is very little objective evidence for most style choices vs most others. Or, at least, they know enough to limit their forceful remarks to the most objective considerations-- such as code which is actually a source of frequent problems.
> Taking the time to rebase, cleanup, and explain your changes in detail will pay huge dividends for any long-lived project. I've literally had successors write me a thank you note for a commit message from over a decade ago because I take this so seriously.
Likewise, though more frequently I've been frustrated to see people make grave errors "fixing" correct code that they would have understood if they bothered to look at the message on the commit which introduced the "error" (or read the adjacent comment).
The culture of writing good, informative commit messages and comments needs to go hand in hand with a culture of reading them. Neither works in isolation.
- zabzonk 6y ago> Not written in the particular arbitrary style that I'm used to Like "arbitrary styles" such as "a function shall not be 500 lines long".
- trade_unionist 6y agoArbitrary like don't use reflection when a dll will do.
- Retric 6y agoAn individual function can quite reasonably be 500 lines long. A giant case statement handling routing is one example. More controversially, if I am gong to need to do a lot of ugly compatibility hacks then I prefer to consolidate them and thus keep most functions clean.
- awinder 6y agoCyclomatic complexity is one of the more well-rigorously studied measure of code quality, I don’t know if I’d pick that hill to die on.
- nemetroid 6y agoA function can be five hundred lines long without having high cyclomatic complexity.
- deleted 6y ago[deleted]
- Retric 6y agoThe average size of functions is independent of the programs total cyclomatic complexity.
- rcxdude 6y agoIt's rigorously studied but it's a crap thing to put an arbitrary restriction on, because it doesn't correlate well enough to warrent that. If you put a restriction on it, bad code still gets through fine while some good code gets made worse to bypass the checks (the biggest one is large switch statements acting as dispatch: Perfectly understandable, but if you split such a thing into multiple functions magically the cyclomatic complexity goes down to satisfy the linter but the code has just gotten harder to understand for static analysis and humans alike).
- burfog 6y agoJohn Carmack, the famous Id Software programmer, tried it out for a few thousand lines of space rocket code, and he liked it. He argues why giant huge functions can be good for maintainability: http://number-none.com/blow/john_carmack_on_inlined_code.html http://number-none.com/blow/john_carmack_on_inlined_code.htm... Previous HN discussions about that: https://news.ycombinator.com/item?id=12120752 https://news.ycombinator.com/item?id=12120752 https://news.ycombinator.com/item?id=8374345 https://news.ycombinator.com/item?id=8374345 https://news.ycombinator.com/item?id=18959636 https://news.ycombinator.com/item?id=18959636
- gregmac 6y ago>> about how a code base "is crap" > Translation: "Not written in the particular arbitrary style that I'm used to" > I've found this to be almost universally true especially when the claim is given forcefully but not immediately backed up with a litany of actual user-impacting serious problems. There's certain code smells that most experienced developers are going to identify that would be almost universally considered bad. Things like poor variable/method/class names, use of magic values, duplicated logic, high coupling, and lack of unit tests. None of these have immediate user-impacting problems, and arguing that's the only thing that matters is very short-sighted. All of these issues will slowly degrade a codebase over the long term -- as the requirements change, new developers start working on the code, and bugs compound other bugs -- and the user impact will be slower delivery and lower quality. Eventually the code will get to a point where the only save is a major rewrite which causes even slower delivery and higher risk of regression in both features and bugs. Writing good variable names at the time the code is created is significantly easier than fixing it months later. Writing the code in a way that can be unit tested is easier up front (and sometimes impossible later, without a rewrite and all the dangers that go with that). There's also a big difference between a code base that's maintained by the same focused person (or small group) for a long time, vs being one of several code bases maintained by a team of people (who may change over time). In the former you can get away with things you can't in the latter case, and moderately or highly successful small projects tend to shift to the latter, and are the ones people will call crap code bases despite their commercial or user-facing success.