I personally like this rule of thumb, if a function is hard to test, it's time to simplify some code.
It's probably time to stop recommending Clean Code (2020)
31–40 of 216 posts
Re: It's probably time to stop recommending Clean Code (2020)
#32Clean Code was one of the first books I read as a History student trying to become a self taught developer. From my point of view, coming from the rigor of historiography, the book was inconsistent and dogmatic. Still I took it as a replacement to talking with an experienced engineer, because that’s how it felt and most of the principles were fine when not taken to the extreme. But now in my career I’ve seen awfully…
Which SOLID principles have you found issues with, either theoretically or in practice? They still seem like broadly sensible principles to me.
Re: It's probably time to stop recommending Clean Code (2020)
#33> Martin states, in this very chapter, that it makes sense to break a function down into smaller functions "if you can extract another function from it with a name that is not merely a restatement of its implementation". But then he gives us: [function that restates its implementation] and [function that restates its implementation] The article's main beef is that Clean Code sets standards that it itself does not mee…
Even outside the context of refactoring/extending an existing codebase the code examples seem bad, look at his example of a prime generator from the bottom of the article. Think it’s more a case of “your own sh*t doesn’t smell”.
Re: It's probably time to stop recommending Clean Code (2020)
#34A common theme not only in software but other industries: Beware of people selling you advice. They are the ones who will breed dogmatic illogical cargo-cults of people whose only rebuttal when questioned is some variant of "because someone who sold me this book that claims it'll make my code better said so", and that can't be a good thing in general. but we assume that Martin doesn't literally mean that every functi…
You can have 1000 5-lines functions in all languages, not only java. Typescript FE projects can be as hard as java ones to read.
It seems to me that there's a lot of prejudice against java, maybe because it has been used by many low skilled devs developing poor quality codebases.
Re: It's probably time to stop recommending Clean Code (2020)
#35I like Carmack's approach to functions the best: "If a function is only called from a single place, consider inlining it. If a function is called from multiple places, see if it is possible to arrange for the work to be done in a single place, perhaps with flags, and inline that. If there are multiple versions of a function, consider making a single function with more, possibly defaulted, parameters. If the work is c…
That would lead to a Big Ball of Mud if given to an inexperienced or reckless developer as i've witnessed many times in my career. The problem with such best practices/patterns/thought pieces is that they stem from highly experienced developers but given to the inexperienced they are like a hand grenade in the hands of an ape.
Re: It's probably time to stop recommending Clean Code (2020)
#36Clean Code was one of the first books I read as a History student trying to become a self taught developer. From my point of view, coming from the rigor of historiography, the book was inconsistent and dogmatic. Still I took it as a replacement to talking with an experienced engineer, because that’s how it felt and most of the principles were fine when not taken to the extreme. But now in my career I’ve seen awfully…
I've recommended it before (I think there's even a blog post of mine written in direct response to this article floating around somewhere): A Philosophy of Software Design is really good.
It isn't so concerned with all of the details about what exact decisions you should make ("how many lines should my function have?" etc), but rather the high-level design choices that go into those decisions. A lot of the book is spent on the philosophy of interfaces, which is the author's way of describing the boundaries between a piece of code and its caller.
It's written by John Ousterhout, of Tcl fame (among many other things) based on his own experience, but also his attempts to teach software engineering to students, and the techniques that worked well for those students in practical situations, so I think it's fairly well grounded in actual advice.
Re: It's probably time to stop recommending Clean Code (2020)
#37Earlier quoted context omitted.
Have you worked with 5000 line functions? Just trying to set breakpoints in them at meaningful points is a nightmare. Give me 1000 5-line functions any day - providing of course they have sensible names (and ideally don't cause unexpected side-effects etc., though when a function is 5-lines long, that's fairly easy to spot; in a 5000-line function, fuhgeddaboudit. My personal guideline is "it should fit on a screen"…
> and ideally don't cause unexpected side-effects etc., though when a function is 5-lines long, that's fairly easy to spot Not easy to spot side effects if the 5 line function calls 999 other 5 line functions, which you have to do if you replace 1 function with 1000 functions. When people start to arbitrarily break up tightly coupled implementations into tiny functions you will get a much worse mess than if they just…
even worse try debugging it with async or gofuncs or threads... just not doable. You can't easily say "jump into that fork" and it just gets worse from there. Small functions and tons of async and then reflection and polymorphism and it's undebuggable.
Re: It's probably time to stop recommending Clean Code (2020)
#38Slightly offtopic but I have summarized my own 20 years of clean coding experience into a system: https://www.fabianzeindl.com/posts/the-codequality-pyramid
I like that post of yours.
If there's one thing I slightly disagree with, it's that I would put Code Performance below Test Performance, but that's because my personal experience ([1]) has been that code performance affects test performance more than anything else.
But still, this is an excellent model, and I'm bookmarking it. Thanks!
[1]: https://gavinhoward.com/2019/08/why-perfect-software-is-near...
Re: It's probably time to stop recommending Clean Code (2020)
#39Clean Code was one of the first books I read as a History student trying to become a self taught developer. From my point of view, coming from the rigor of historiography, the book was inconsistent and dogmatic. Still I took it as a replacement to talking with an experienced engineer, because that’s how it felt and most of the principles were fine when not taken to the extreme. But now in my career I’ve seen awfully…
I'm still amused by claims that the book is dogmatic when these paragraphs are in the opening chapter:
> Consider this book a description of the Object Mentor School of Clean Code. The techniques and teachings within are the way that we practice our art. We are willing to claim that if you follow these teachings, you will enjoy the benefits that we have enjoyed, and you will learn to write code that is clean and professional. But don’t make the mistake of thinking that we are somehow “right” in any absolute sense. There are other schools and other masters that have just as much claim to professionalism as we. It would behoove you to learn from them as well.
> Indeed, many of the recommendations in this book are controversial. You will probably not agree with all of them. You might violently disagree with some of them. That’s fine. We can’t claim final authority. On the other hand, the recommendations in this book are things that we have thought long and hard about. We have learned them through decades of experience and repeated trial and error. So whether you agree or disagree, it would be a shame if you did not see, and respect, our point of view.
Generally dogmatic people don't say, in short, "We could be wrong, we don't think we are, but go see what other people have to say, too.".
Re: It's probably time to stop recommending Clean Code (2020)
#40Towards the end of my tenure in a team, a new boss instituted mandatory viewing sessions of Martin's training videos; I grew somewhat averse of them.
While the heart of Martin's teachings are about expressivity and semantics, the praxis is much more about recipes than about what matters to me as a professional, which is:
1. Well-definedness of the computation being done (in a mathematical sense of the word),
2. Engineering, that is establishing of a connection between human narratives about what the SW should do with the program's structure.
Overall, it seemed to me that Martin is first and foremost trying to sell to sell a certain paradigm of competency to corporate cookie-cutter-culture organizations.
My issues with this paradigm of competency are that:
1. Doing it properly requires a massive investment, which does not make business sense.
2. As is often the case, this paradigm makes it easy to feign competence without actually being competent, which is damaging to organizational trust.