91–100 of 220 posts
Earlier quoted context omitted.
Not the OP but HTDPv2 is a solid recommendation here
I don't understand why you would acronym your book recommendation. Anyone this would be a useful recommendation to would not know about it already, and hence not understand the acronym. For those wondering, "How to Design Programs"
Earlier quoted context omitted.
Robert C Martin's (who is not my uncle) Clean Code book/advice is what I would call junior programmer material. Its good to get someone started to think about better ways of writing software (albeit is hasn't aged very well). I don't recommend it to juniors anymore because it hasn't aged well and is for my taste hyperbolic in its promises. IMHO clean code also is more focused on code implementing "business logic" tha…
This begs the question: what do you recommend instead?
It is debatable if Clean Code actually improves the programmer efficiency and programs readability. I find people applying it religiously often create over-complex designs like FizzBuzz Enterprise. Even Uncle Bob's examples are not the state of the art in readability: https://qntm.org/clean The main problem seems to be that Clean Code is mostly a premature optimisation in code flexibility. It makes code more complex…
Robert C Martin's (who is not my uncle) Clean Code book/advice is what I would call junior programmer material. Its good to get someone started to think about better ways of writing software (albeit is hasn't aged very well). I don't recommend it to juniors anymore because it hasn't aged well and is for my taste hyperbolic in its promises. IMHO clean code also is more focused on code implementing "business logic" tha…
Earlier quoted context omitted.
Ok. Fair enough. I just find that what Uncle Bob calls clean code is often not clean code for me. E.g. preferring inheritance over switch is less readable. Flexibility/extensibility and readability are different things.
> E.g. preferring inheritance over switch is less readable. Surely this depends on the context? If you have a many different classes it tend to lead to cleaner code if you encapsulate the class-specific logic with the class definition rather than intermingled in multiple giant switch statements. In particular you can add new classes without making the rest of the code more complex. Of course there are cases where a s…
Earlier quoted context omitted.
I used to like to rewrite code that I thought was "ugly" because it was not written in the modern way or it was not very generic or whatever. I thought that doing that was often pretty easy so I thought "why has no one done this already?" Later I realized that the fact that it was easy to change was what made it good and the changes I wanted to make to it would probably just make it more complicated. That's the dange…
that last paragraph is an excellent description of the problem!
Software solves business problems. Code that meets its requirements needs to be left alone. Developers just changing code because they feel like it need some coaching. They're wasting everybody's time for reasons that amount to "I like it My Way".
So, with normally performing developers, the only code that changes is the code that needs to change. Good or bad only has an influence on the cost of a change.
It is debatable if Clean Code actually improves the programmer efficiency and programs readability. I find people applying it religiously often create over-complex designs like FizzBuzz Enterprise. Even Uncle Bob's examples are not the state of the art in readability: https://qntm.org/clean The main problem seems to be that Clean Code is mostly a premature optimisation in code flexibility. It makes code more complex…
I'm starting to hate programming discussions, after you've read a lot of them they're predictable, boring as hell and you can argue endlessly just because you value a little bit different things. This discussions is yet another, nothing special way of saying: context matters. You have a list of requirements of what you want to achieve, some of them do appear during development and you develop against this. I have com…
A: If I do X, then this happens...
B: Yeah but I don't care about X.
A: You are not a professional if you don't care about what I care about.
Now that this debate has raised some dust, I guess Bob has already started writing the "Clean Performance" book in order to continue to milk the series and stay in the spotlight.
Earlier quoted context omitted.
Robert C Martin's (who is not my uncle) Clean Code book/advice is what I would call junior programmer material. Its good to get someone started to think about better ways of writing software (albeit is hasn't aged very well). I don't recommend it to juniors anymore because it hasn't aged well and is for my taste hyperbolic in its promises. IMHO clean code also is more focused on code implementing "business logic" tha…
Uncle Bob,the eternal noob of programming.
Earlier quoted context omitted.
> E.g. preferring inheritance over switch is less readable. Surely this depends on the context? If you have a many different classes it tend to lead to cleaner code if you encapsulate the class-specific logic with the class definition rather than intermingled in multiple giant switch statements. In particular you can add new classes without making the rest of the code more complex. Of course there are cases where a s…
Switch statements don't have to be giant. Hint: you can still extract each branch to a separate function / module. But what is more readable about them is the control flow: the condition is explicit and all targets are easy to find. A codebase using switches/ifs and function calls can be easily navigated with ctrl-click in most IDEs. A codebase relying heavily on interfaces and inheritance cannot.