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

371–380 of 554 posts

Re: Clean Code vs. A Philosophy Of Software Design

#371

Post by ninetyninenine »

ddejohn wrote: post #368
ninetyninenine wrote: post #281

Earlier quoted context omitted.

No. I’m talking about genius. Not savant. Savants likely can’t relate to your emotions. Geniuses can. The difference is just if it takes them 1 second to parse what takes you 5 minutes to do the same they often don’t realize this unless you tell them. That being said what I talk about lives on a gradient. The smarter you are the greater degree of tendency you have to write shitty code. The cleaner your code the highe…

This is the silliest thing I've ever heard

Probably because you think you're smart AND you write excessively clean code and are excessively anal about it. Whether you actually are smart is a different story.

Re: Clean Code vs. A Philosophy Of Software Design

#372

Post by WillAdams »

seanwilson wrote: post #327
WillAdams wrote: post #65

Earlier quoted context omitted.

That was exactly the approach taken by Prof. Ousterhout in setting up the class which lead to this book --- rather than just having students turn in working code for a grade, the code is reviewed with the student and the student then works to make it better --- in turn, the 2nd edition of the book was informed by the experience of teaching the class and the author actually changed his position based on the experience…

Why is that convincing though? Students aren't experienced coders, aren't working in large teams, and student assignments aren't like long-term large commercial projects. If you mean the additions here https://web.stanford.edu/~ouster/cgi-bin/book.php , I read these and it still sounds like general rules of thumb you'll only really learn and understand by practicing a lot e.g. "In my experience, the sweet spot is to…

It's better credentials and experiential basis than most other programming books.

Moreover, it is the students' inexperience which give this text credence --- since it results in their making errors and poor architectural/design choices it affords the chance of correction.

I think it is remarkable that the author switched from "modules should be specialized" to "modules should be generalized" (rough paraphrasing, mailed my copy to Brazil and waiting to buy a replacement).

If you know of other books which you merit recommendation and which have a similar or better context for their authorship and exposition, I would be glad to hear of them.

Re: Clean Code vs. A Philosophy Of Software Design

#373

Post by Izkata »

WillAdams wrote: post #284
Hasu wrote: post #263

> I bemoan the fact that we must sometimes use a human language instead of a programming language. Human languages are imprecise and full of ambiguities. Using a human language to describe something as precise as a program is very hard, and fraught with many opportunities for error and inadvertent misinformation. This quote from Uncle Bob is shameful, considering that he has made 100% of his career on writing English…

An interesting contrast to it is Ousterhout's observation: >If you can visualize a system, you can probably implement it in a >computer program.... This means that the greatest limitation in writing >software is our ability to understand the systems we are creating. Though interestingly it is in marked contrast to a different statement in the "Software Design Book" Google mailing list: >John Ousterhout, Aug 21, 2018,…

Structure graphs are rarely useful for me, but visualizing the data flow is how I think about code in general. Sometimes it's graph-like, but more wishy-washy and I'm only holding the relevant parts for the task at hand in my head rather than everything.

Re: Clean Code vs. A Philosophy Of Software Design

#374

Post by wglb »

WalterBright wrote: post #39
WalterBright wrote: post #38

One method of commenting that has paid off for me the most was inserting links to: 1. the online documentation of the function being called 2. the instruction documentation for an instruction being generated, inserting 3. the issue that the code fixes 4. the specification of what the function is trying to implement Then I fixed my text editor to enable click on those links.

I also fixed the disassembler to also add a clickable link to the instruction spec page for each instruction.

I did that back in the day (before we could click on anything) about what the compiler was thinking as it generated the code. That was fun.

Re: Clean Code vs. A Philosophy Of Software Design

#375

Post by TeMPOraL »

nuancebydefault wrote: post #363
jsbg wrote: post #325

Earlier quoted context omitted.

> Who else has had to deal with idiots who froth at the mouth when you exceed an 80 line character margin? Not once in my 11 year career. But almost every codebase I've worked on has had debilitating maintainability issues because the only principle other engineers seemed to follow was DRY, at the sacrifice of every principle in SOLID.

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.

clearTotals() arguably made more sense than other "abstractions", on the grounds that if you have more than one piece of state to reset/initialize, you want to centralize the knowledge of which variables must be set together - otherwise it's too easy to add another piece of state and forget to set it everywhere it should be.

Of course, a method is but one of several ways you could capture that information, and not always the best one.

Re: Clean Code vs. A Philosophy Of Software Design

#376

Post by MetaWhirledPeas »

I think the reason most people have a problem with Uncle Bob is because they know their own practices are a far cry from his recommendations, and they take his prescriptive and uncompromising advice as a personal attack.

I also wonder how many people interpret his advice as that of a mindless, pedantic dictator.

My own introduction to UB was from some random YouTube video he made about programming languages, so my first impression of him included his humor and his ability to see both sides of an issue while being unafraid of having a strong opinion. I really enjoy speaking with and listening to people with strong, long-marinated opinions, regardless of whether I agree or not. At the very least it means they've put a lot of thought into it, which makes for better discussion and learning.

I also lack a long history of code commits, being more of a dabbler here and there, so perhaps I have a smaller surface area for UB's jabs to land upon. Still, I acknowledge that a Clean Code Nazi would probably rip me to shreds for some of the practices I've followed and some that I continue to follow. But improvement is a much more achievable goal than perfection, and gleaning valuable information is better than being dogmatic.

In the end I love listening to UB talk. I don't follow all his practices but I do keep them in the back of my mind. If not worth following strictly they are always worth considering, especially the intent behind them.

So when I see his opinions on comments or his opinions on abstraction and variable naming my first instinct is not to lament about how he is poisoning our youth or insulting my code, but rather to ask myself how I can make use of his perspective. I'd encourage others to do the same; it's much more fun that way, not just for programming but for everything.

As for those of you stuck in "Clean Code" hell with oppressive supervisors demanding strict adherence... that sounds like a personal failure, or a personal incompatibility, or both. I would blame the messenger there, not the message.

Re: Clean Code vs. A Philosophy Of Software Design

#377

Post by ninetyninenine »

yakshaving_jgt wrote: post #342
ninetyninenine wrote: post #329

Earlier quoted context omitted.

Yeah. That's where it should be. Usually though you don't need much parsing as it's coming in as json or a protobuf. But the interface between IO and your code program is where exceptions and errors can occur. Beyond this boundary your code should be pure and deterministic. Since you're doing your own parsing rather then using schema validators and existing formats like json, yes your code is doing A LOT of data proc…

What you’re describing isn’t exactly new territory for me. Maybe you’re writing for the room, and not immediately for my benefit. Parsing is kind of… everywhere. Path piece instances? Parsing. Forms? Parsing. The whole point of smart constructors is parsing. Deserialising from the persistence layer? Parsing. Sure, JSON and Protobuf also, but even when relying on a robust library like aeson, we still write tests. Why…

I wouldn't because the deserialization library is tested to death by the library maintainers.

Re: Clean Code vs. A Philosophy Of Software Design

#378

Post by WillAdams »

kragen wrote: post #358
WillAdams wrote: post #355

Earlier quoted context omitted.

Curious what Stallman has to say about Robert C. Martin --- looked, but couldn't find anything....

Not about Martin. About Ousterhout. 27-30 years ago.

Right, I was curious if _in addition to_ that well-known comment there was an evaluation by Stallman of Bob Martin extant.

Re: Clean Code vs. A Philosophy Of Software Design

#379

Post by DeathArrow »

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…

For many C#, Java and C++ engineers Uncle Bob is their savior and GoF are the apostles.

Everything should follow SOLID and clean principles and be implemented using design patterns.

Re: Clean Code vs. A Philosophy Of Software Design

#380

Post by mattmanser »

tikhonj wrote: post #337
hliyan wrote: post #196

Earlier quoted context omitted.

To restate something I've said here last month: I'm fond of saying that anything that doesn't survive the compilation process is not design but code organization. Design would be: which data structures to use (list, map, array etc.), which data to keep in memory, which data to load/save and when, which algorithms to use, how to handle concurrency etc. Keeping the code organized is useful and is a part of basic hygien…

I disagree entirely. Design is fundamentally a human-oriented discipline, and humans work almost exclusively with code before it is compiled. A strong shared mental model for whatever we're doing is as much a part of software development as any code that runs on a computer. Programming languages can (should!) be amazing tools for thought rather than just tools for making computers do things; using these tools to figu…

I agree, I recently keep having the thought that by far the hard part of programming is code organisation. Whether that's where the files go, or how you've wrapped up commonly used idioms like validation or data access in easy to use abstractions.

It's so easy to get it spectacularly wrong and end up in a mess.

And it's seems so deceptively pointless at the start. It's easy to throw together a greenfield project and get something working, but make a complete mess of organisation. But then it becomes so expensive so quickly to then make changes to that code.

I've joined quite a few projects after 1/2 years of someone else making the project. And so often it's such an imposing mass of code that basically does sod all. Bad architects who don't understand why they're even using the patterns they are or mid/junior-level coders making projects is basically a recipe for the project just grinding to a halt just when it looks like you're getting near the end.

It's when 1,000s of lines are easily refactored to 100s that you start thinking, how can these people honestly believe they have the ability to lead a project? They are so clearly completely out of their depth it's depressing.

We seem, as an industry, to have a complete inability for management to distinguish genuine senior developers from people who will never be.

Post reply on HN