Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Clean Code vs. A Philosophy Of Software Design

github.com

Post reply on HN
Print view View original

501–510 of 554 posts

Re: Clean Code vs. A Philosophy Of Software Design

#501

Post by manmal »

motorest wrote: post #148
manmal wrote: post #114

Earlier quoted context omitted.

> The main goal of code is to help a programmer understand it and modify it easily and efficiently. What machines do with it is of lower priority. This mentality sounds like a recipe for building leaky abstractions over the inherent traits of the von Neumann architecture, and, more recently, massive CPU parallelism. Bringing with it data races, deadlocks, and poor performance. A symptom of this mentality is also that…

> This mentality sounds like a recipe for building leaky abstractions over the inherent traits of the von Neumann architecture, and, more recently, massive CPU parallelism. Bringing with it data races, deadlocks, and poor performance. No,not really. Just because you think about how to name functions and what portions of your code should be easier to read if the were extracted to a function,that doesn't mean you are c…

I was quoting you, where you said readability takes precedence over technical concerns. That‘s what I‘m challenging.

Every extra function call and object instantiation has a real cost, and abstracting ourselves away from the bare metal means we need to pay the price in terms of performance. Some very nicely readable algorithms are just sub-par in all dimensions except readability. We should optimize for performance and correctness, and readability comes second.

Re: Clean Code vs. A Philosophy Of Software Design

#502

Post by atoav »

Aurornis wrote: post #400
sunrunner wrote: post #387

Earlier quoted context omitted.

For some reason in software there seems to be an incredibly large space for non-evidence based thinking and belief systems. I wonder if that's because in a lot of cases (depending on the domain) the space of possible valid/working solutions is near infinite, and if you don't have hard requirements that are backed up by measurements you're free to concieve of any valid system structure and justify it as 'better' witho…

> For some reason in software there seems to be an incredibly large space for non-evidence based thinking and belief systems. The secondary problem is that book authors have become extremely good at inventing pseudo-evidence to support their claims. It most commonly takes the form of “I talked to X companies with Y total number of employees over Z years and therefore I know what works best”. If you cut out all of the…

Yet we have the evidence out there. The only problem is that it is just the negatives — it tells you what to avoid and not what you should do.

Other than with civil engineering where each bridge failure will be studied by the whole community, in programming most people shrug it off as "software error there is nothing we can do" and move on.

If we truly want to progress in terms of code quality we need to anchor our guiding principles in the lessons learned from failed projects and check all new positive principles against those.

Re: Clean Code vs. A Philosophy Of Software Design

#503

Post by ninetyninenine »

colonCapitalDee wrote: post #436
ninetyninenine wrote: post #334

Earlier quoted context omitted.

[flagged]

> Then you've never been around the smartest people. Likely you've been around smarter then average people. This is totally unfalsifiable. I claim that the smartest people around always wear clown shoes to work. If you disagree, it's simply because you haven't met any of the people I'm talking about. QED

So. I'm offering my anecdotal opinion. If you want to make it invalid because you can't falsify it so be it.

It's like proving the ground exists when you jump off the bed in the morning. The overly nerdy and stupid HNer can't even move an inch off the bed until the scientific method is employed in attempt to falsify whether the groun doesn't exist. OoooooOOh.

I'm just offering my anecdota opinion here. If you can't listen to normal conversation and you can only read research papers (which mind you suffers from a replication crisis) then more power to you.

Re: Clean Code vs. A Philosophy Of Software Design

#504

Post by whstl »

sunrunner wrote: post #416
Aurornis wrote: post #400

Earlier quoted context omitted.

> For some reason in software there seems to be an incredibly large space for non-evidence based thinking and belief systems. The secondary problem is that book authors have become extremely good at inventing pseudo-evidence to support their claims. It most commonly takes the form of “I talked to X companies with Y total number of employees over Z years and therefore I know what works best”. If you cut out all of the…

> a world of social proof Which results in the idea of 'good practice', 'best practice' and 'bad practice', and nobody wants to be seen as the person doing things that are considered bad practice, because that would imply that you're a bad developer. And I almost always hesitate to use the term 'engineer' because as far as I know engineering is considered to be a practice/process that uses measurements and results to…

I'd say Asbestos is more comparable to a project or technology having too many CVEs, which goes well with the US government asking people to stop using C and C++.

The problem I'd say is the reactions from our community to such pleas. My degree and original profession is Electrical Engineering, and Engineers not as personally attached to the tech as software developers are, nor they conduct themselves like this.

Re: Clean Code vs. A Philosophy Of Software Design

#505

Post by notachatbot123 »

soulofmischief wrote: post #402
ilitirit wrote: post #145

It still blows my mind how dogmatic some people can be about things like this. I don't understand why anyone takes these things as gospel. Who else has had to deal with idiots who froth at the mouth when you exceed an 80 line character margin? And it's not just programming styles, patterns and idioms. It's arguably even worse when it comes to tech stacks and solution architecture. It's super-frustrating when I'm deal…

On my Macbook Pro M2, having a browser window on one half of the screen, and my IDE on the other, with a file tree viewer pane and another pane for my LLM tools, a terminal pane at the bottom... I've never been more pressed for real estate for my actual code editing pane. Even 80 chars has me scrolling horizontally. Secondary monitors help but not when you frequently work away from your desk.

Why only use half the screen for your IDE? Your brain has to switch anyways so just make your IDE and browser fullscreen windows and alt-tab when needed.

Re: Clean Code vs. A Philosophy Of Software Design

#506

Post by dsego »

tqwhite wrote: post #426
wglb wrote: post #294

Earlier quoted context omitted.

Yes, Uncle Bob is certainly capable of being pedantic. A friend of mine, a Smalltalk Consultant, partnered with him for a while. "With Uncle Bob, it's his way or the highway." His clean code work is certainly pretty dogmatic. As I recall, he says that Java is not object oriented. But if my memory serves me correctly, his book about C++ (Designing Object-Oriented C++ Applications Using the Booch Method) has some excel…

Bob's had a long life with too much success. He really believes in himself. But, I have to say that the other guy was aggressive and bad even though I am more inclined to agree with him. He willfully misrepresented Bob's ideas. I thought he presented more misguided certainty than Bob. No Bueno.

I didn't read it as aggressive, more like engaged in the discussion, he really wanted to get to the bottom of things and get his views and opinions challenged, but UB was a bit defensive and closed. Even though UB has strong opinions he wasn't as engaged in building a case for them, he just tried not to budge or maybe he conceded smaller points and then retreated to a less dogmatic stance.

Re: Clean Code vs. A Philosophy Of Software Design

#507

Post by dsego »

kraftman wrote: post #346
ctrlp wrote: post #37

I've enjoyed both books but Uncle Bob is something you grow out of. He was a bit of a cult figure at the time. Trying to actually follow the guidelines in Clean Code taught me a lot about "over-decomposition" and, ultimately, how not to write code. It reminds me it's possible to take aesthetics so far the results become ugly. Fussing over a proliferation of small functions that do only one thing is a kind of madness.…

it has been years since I read the book, but I'm surprised that there's so much hatred for it here. From memory it seemed like fairly harmless things like give things good names, try to make the code readable, dont comment what the code does but why, use consistent formatting, avoid duplication. Other than people going overboard with empty classes and inheritance Ive not really seen a problem of people breaking down…

Please read it again, you might see it differently now.

Re: Clean Code vs. A Philosophy Of Software Design

#508

Post by lodovic »

jsbg wrote: post #435
nuancebydefault wrote: post #363

Earlier quoted context omitted.

Most code that i clean up is a lot easier to maintain after making it a lot DRYer. The point is not about being DRY, on itself, though. The point is that the code then has better abstractions which are easy to reason about. UB seems to take abstractions a lot too far, replacing e.g. 2 lines of very clear code with some cleartotals abstraction.

DRY is about ensuring that the same code doesn't have to change in two places because the engineer changing it in one place might not know that. But so many applications of DRY mindlessly violate the single responsibility principle and create coupling where there shouldn't be.

I always understood that the main reason for DRY is to ensure that the same business logic is managed only once in the codebase. I don't really care about having four similar functions for reading a file from disk, but I definitely wouldn't want multiple UserDiscountCalculator class implementations scattered all over the codebase.

Re: Clean Code vs. A Philosophy Of Software Design

#509

Post by sirwhinesalot »

rswail wrote: post #73
pinoy420 wrote: post #7

Earlier quoted context omitted.

In typical HN commenter smugness. It took me less than that to realise it was bullshit. It didn’t make things clear, it made them more abstract and more resistive to change. Similarly with DDD. Just build what you need and deal with the consequences of inevitable change later. No one cares if you miraculously perfectly modelled your “definitely the final form” of your domain from day 0. Oh and TDD?! Ah yes those perf…

DDD is a good way to extract the business logic from the implementation. By modelling the business you raise the business logic up to a 1st class element. By implementing the business objects you encapsulate their functionality in the business. The words "Account" or "Outstanding Balance" have business meanings. Modelling them allows you to express the business logic explicitly. It also allows you to create tests tha…

There's a huge difference between understanding the domain and modelling it as objects. Accounts and Balances have no behavior.

Re: Clean Code vs. A Philosophy Of Software Design

#510

Post by john_the_writer »

brianmcc wrote: post #300
wglb wrote: post #294

Earlier quoted context omitted.

Yes, Uncle Bob is certainly capable of being pedantic. A friend of mine, a Smalltalk Consultant, partnered with him for a while. "With Uncle Bob, it's his way or the highway." His clean code work is certainly pretty dogmatic. As I recall, he says that Java is not object oriented. But if my memory serves me correctly, his book about C++ (Designing Object-Oriented C++ Applications Using the Booch Method) has some excel…

>> ... TDD is unlikely to help you solve problems that are beyond incremental changes. Thank you for expressing this niggling problem with TDD. Personally I just cannot use it for "new stuff", I need to explore and create direct with "real" code for anything non-obvious.

I suppose it depends on how you use it.. If you view it like you would a bit of paper and a pencil then it works a treat.

I want this to do X when I ask it with Y param. If you write out your spec's before you sit down to code.

When a user enters a bad password... print this to screen

TDD works great for new stuff when viewed as paper replacement.

Post reply on HN