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

291–300 of 554 posts

Re: Clean Code vs. A Philosophy Of Software Design

#291

Post by mrkeen »

Kerrick wrote: post #253
mrkeen wrote: post #155

Earlier quoted context omitted.

> Your Order class has a collection of Product items, but you can update an order, cancel a order, repeat an order, etc. This behavior should be member functions. This is how to fuck up OO and give it a bad name: order.update(..) // Now your Order knows about the database. order.cancel(..) // Now your Order can Email the Customer about a cancellation. order.repeat(..) // Now your Order knows about the Scheduler. What…

We have a disagreement about the core of OOP. In English, a simple sentence like "The cat eats the rat" can be broken down as follows: - Cat is the subject noun - Eats is the verb - Rat is the object noun In object-oriented programming, the subject is most often the programmer, the program, the computer, the user agent, or the user. The object is... the object. The verb is the method. So, imagine the sentence "the cu…

The comparison to English grammar is unnecessary. I didn't use it in my argument and you said it doesn't work that way either, so when you arrive at

> The order is the object noun, and is what is being canceled. Thus, order.cancel()

You've just restated the position I argued against, without an argument.

Re: Clean Code vs. A Philosophy Of Software Design

#292

Post by frozenlettuce »

ahoka wrote: post #224
rester324 wrote: post #21

Earlier quoted context omitted.

Uncle Bob is one of the core contributors to Fitnesse, which had moderate success in the Java popularity era back in the day. Also, you do understand that people worked as software engineers even before Github became popular, or open sourcing to begin with, do you? So if someone is 60+ year old, chances are that most of his work has never been open sourced, and his work was targeting use cases, platforms, services wh…

Do you mean commits to the project like this crap: https://github.com/unclebob/fitnesse/commit/d6034080a04c740c... This level of pointless obfuscation would not survive a code review at any sane dev team.

It's the kind of commit that you get from someone that wants to look productive but is just renaming variables in their IDE.

Re: Clean Code vs. A Philosophy Of Software Design

#293

Post by geodel »

dkarl wrote: post #271
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…

> 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.

Re: Clean Code vs. A Philosophy Of Software Design

#294

Post by wglb »

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…

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 excellent parts. His description of the difference between a class and an instance is one of the better ones.

Then there is the famous sudouko puzzle incident, in which a student trying test-driven development can't get the solution. It is a very instructive incident which illustrates the TDD is unlikely to help you solve problems that are beyond incremental changes. Peter Norvig's solution makes that very clear. Uncle Bob does not seem to realize that.

> Who else has had to deal with idiots who froth at the mouth when you exceed an 80 line character margin?

But I admit in my youth, I was pretty dogmatic about languages and development practices, so I've been that guy.

Re: Clean Code vs. A Philosophy Of Software Design

#295

Post by spacechild1 »

IMO the "PrimeGenerator" example from Clean Code is horrendous and completely unreadable! This would be so much better as a single method/function with a few interspersed comments that explain the algorithm. I mean, just look at this abomination:

  private static boolean
  isMultipleOfNthPrimeFactor(int candidate, int n) {
    return candidate ==
      smallestOddNthMultipleNotLessThanCandidate(candidate, n);
  }
Not only is the method itself completely pointless, it also happens to have side effects! Who would expect this from the method name? So much for self-documenting code... Ousterhout rightfully calls him out on this bullshit.

In fact, Ousterhout makes such great points that I really want to read his book. Conversely, I'm now even less inclined to read Clean Code.

Re: Clean Code vs. A Philosophy Of Software Design

#296

Post by tremon »

rswail wrote: post #71
Willingham wrote: post #44

Earlier quoted context omitted.

> If you want to write good code, read good code. As a junior in the field working at a small company, I often rely on this community for guidance, and this seems the most sound advice on this thread.

Agreed. Some other heuristics: * Every if statement is a chance of a bug because the code has two or more paths to follow. Keep the choice making at the business/requirements level of the code, not hidden inside lower level decomposition. * A switch statement that is not exhaustive (ie covers all possible values) is a change of a bug, especially if there is no default case. Modern languages with better type systems m…

Every if statement is a chance of a bug because the code has two or more paths to follow

This is known as the cyclomatic complexity of a program: https://en.wikipedia.org/wiki/Cyclomatic_complexity

A corollary to this is that it is also beneficial to converge separate paths as quickly as possible (e.g. using non-nullable types and default values) or converge them all to the same place (e.g. nonlocal exception handling).

Re: Clean Code vs. A Philosophy Of Software Design

#297

Post by Scubabear68 »

Copenjin wrote: post #126

You just need to work on one project built by someone that implemented Uncle Bob recommendations blindly when the books came out to know how much they are worth. There were some low hanging fruits to pick at the time regarding trying to be better at software engineering and he generated some text about them. Full of terrible advices, he never wrote anything significant (in scope and notoriety) during his time as a so…

It is very instructional to read the source code to FitNesse framework.

https://github.com/unclebob/fitnesse

You can see how all his ideas come together into a ball of hundreds of almost empty classes, and gems such as "catch Throwable".

Re: Clean Code vs. A Philosophy Of Software Design

#298

Post by analog31 »

hliyan wrote: post #196
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…

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…

Granted, while I program a lot, I'm not employed as a programmer per se. My impression is that programming is easy and fun, but software develoment is hard and laborious. Things like hygiene are among the differences between the two.

Re: Clean Code vs. A Philosophy Of Software Design

#299

Post by pcblues »

On reflection, my attitude to books like these indicated where I was in my understanding of programming. They used to be useful life-buoys that one clung to for dear life early in one's career in a fast-moving and often-changing industry. Then they become an interesting side-note reminding one of what they clung to as the good precepts that served them well stand out from the rest of the books. And finally they become unnecessary and seemingly dogmatic when one has become adept at swimming. In other words, essential reading depending on where you find yourself :) Disclaimer: out of these two, I only read Clean Code.

Re: Clean Code vs. A Philosophy Of Software Design

#300

Post by brianmcc »

wglb wrote: post #294
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…

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.

Post reply on HN