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

311–320 of 554 posts

Re: Clean Code vs. A Philosophy Of Software Design

#311

Post by okaleniuk »

floydnoel wrote: post #188
okaleniuk wrote: post #159

It's sad that we demoted the field from engineering to philosophy. But it is what it is. Next step - fashion and belief.

philosophy is the basis of reason, math, and science. it's sad that "engineers" don’t understand it or it's import.

Engineers believe in definitions. By definition, philosophy is not a scientific discipline, because as soon as a discipline becomes scientific it... stops being philosophy.

As Alexander Pyatigorsky famously wrote, "the value of philosophy is in that nobody needs it".

Re: Clean Code vs. A Philosophy Of Software Design

#312

Post by machine_ghost »

disgruntledphd2 wrote: post #175
zero_shift wrote: post #147

Earlier quoted context omitted.

(English tip: advice isn't a countable noun, so you don't pluralise it) I agree entirely. My encounters with Uncle Bob were as a junior developer receiving advice [no "s"] from other junior developers. And yes, I too find it suspicious how many mavens of the "Agile era" never really managed to ship anything.

It's important to note that Kent Beck is not one of those people, as he shipped the first unit testing library, as well as a bunch of ones in other languages later. Like, I personally prefer the bare assert style of testing (like pytest), but the junit style is basically everywhere now.

Kent Beck is just as bad as Uncle Bob! He drank his own proverbial Kool-Aid and went all in on the crazy XP programming fad he started (... which contains brilliance like requiring pair programming for every line of code written).

Look, both authors are very smart people who have great insights into development that we can all learn from ... but both also have the failing of being way too in love with their own ideas.

It blinds them to the flaws in those ideas, and makes it so when you read their work you have to be skeptical and evaluate each individual idea on their own.

Re: Clean Code vs. A Philosophy Of Software Design

#313

Post by marcosdumay »

Mawr wrote: post #61
sudobash1 wrote: post #10

There is an important case for comments that neither of them touched on. Sometimes you are dealing with bugs or counterintuitive processes beyond your control. For example, I am writing some driver software for a USB device right now. It is so easy to get the device into a bad state, even when staying within the documented protocol. Every time I implement a workaround, or figure out exactly how the device expects a m…

Sounds like you should instead be making these invalid states unrepresentable by encoding them in types and/or adding assertions. Especially if you're exposing them as interfaces, as your example function names would imply.

The GP is making those invalid states unreachable by writing a device driver.

Re: Clean Code vs. A Philosophy Of Software Design

#314

Post by [deleted] »

wesselbindt wrote: post #274
felizuno wrote: post #248

Earlier quoted context omitted.

Clean Code zealots are consistently some of the least likable, least productive, least pragmatic people I have ever worked with. I've had multiple clients where the whole team is threatening to quit unless the CC zealot is fired. And when they are fired guess what - bugs go down, shipped features go up, and meetings become productive. "Idiots who froth at the mouth" is an understatement IMO

This too seems like a fairly hardline stance to take. I think it's not surprising that you'd have a hard time collaborating with people you'd refer to as unlikeable, unproductive, unpragmatic, overzealous, frothy idiots. It reminds me of the standard joke about veganism: "how do you know someone is vegan? Don't worry they'll tell you" It's a very ironic joke, because the people I hear talking about veganism the most…

[deleted]

Re: Clean Code vs. A Philosophy Of Software Design

#316

Post by dominicrose »

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…

Square people are never going to agree with cool people. You can be cool and code some monstruosity or you can be square and say "we have to rebuild this entire project from scratch" everytime you see a long method.

Re: Clean Code vs. A Philosophy Of Software Design

#317

Post by coliveira »

ninetyninenine wrote: post #205
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…

Well I mean they wrote books about it and one guy had the audacity to call his opinion a “philosophy” even though it’s just an arbitrary opinion. Most of software is about assigning big words and over complicated nomenclature to concepts and these things masquerade as things with deeper meaning when in reality it’s just some made up opinion. Software design is an art. It is not engineering and it is not science. That…

The issue is that programming is communication. Communication is indeed a form of art. Programming is not just giving instructions to machines, if that was the case we would be happily using binary code. So we have two dimensions, the first one is giving the binary instructions, but the other one is how to make these instructions understandable by humans, including ourselves.

Re: Clean Code vs. A Philosophy Of Software Design

#318

Post by gibibit »

voidhorse wrote: post #240
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…

I think it stems from fundamental misunderstandings about what it is one is actually trying to do when writing code. Coding is about building a computable model of some facet of existence, usually for some business. When it comes to model building, comprehension and communication are paramount. Performance and other considerations are also important but these are arguably accidental features of machines and, in an id…

It seems that each software design/development system, ideology, and practice has a good reason it was created, and has certain inherent benefits. Each may solve (or at least help with) some common problem.

For instance, abstraction is good and short methods are good to some extent (who wants to read a 2000-line function?), but as John points out in the article, these can be taken too far, where they create new and perhaps worse problems.

It seems there's a pendulum that swings back and forth. We go from big up front design, to Extreme Programming, to a pervasive object-oriented design culture, back to other paradigms.

Re: Clean Code vs. A Philosophy Of Software Design

#319

Post by dkarl »

geodel wrote: post #293
dkarl wrote: post #271

Earlier quoted context omitted.

> Keeping the code organized is useful and is a part of basic hygiene, but it's far from the defining characteristic of the craft. I'm with you, but I don't think it makes sense to elevate one absolutely over the other as the "defining characteristic." Either one can tank the development of a piece of software and prevent it from coming into being in a useful way. Arguments about which aspects of software are more im…

> Any aspect of software development will feel like the "defining characteristic" if it threatens to kill your project. That does not make sense to me. There can be thousand things that can kill project. One has to consider what are the odds for them.

How would you define the odds for the industry as a whole? The odds depend on the project, the team, the tech stack, and the organizational environment.

No matter how long I work (twenty-five years so far) I think my personal experience is only enough to know that if I've seen something, it probably happens fairly often. If I've never seen something, it still might be common for all I know.

Re: Clean Code vs. A Philosophy Of Software Design

#320

Post by __mharrison__ »

nicce wrote: post #191
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…

> Always keep in mind that sometimes the only difference between yourself and the person writing the book/blog/article is that they actually wrote it. And that their opinions were written down don't make them fact. Apply your own mind and experience. But that difference is actually huge. I think you are downplaying the value of the writing process. Assuming that writer is acting in good faith and truly tries to provi…

Writing is an excellent way to determine your opinions. There's a large gap between ideas and those formed when writing said ideas.
Post reply on HN