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

Goodbye, Clean Code

overreacted.io

Post reply on HN
Print view View original

461–470 of 599 posts

Re: Goodbye, Clean Code

#461

Post by flavio81 »

_old_dude_ wrote: post #458
_y5hn wrote: post #444

Earlier quoted context omitted.

Except exceptions are rarely understood and used correctly by most programmers. They can simplify program structure, but at the expense of proper errorhandling and error mitigation strategies. Golang is still in the sort of niche that builds databases, queues, container-orchestration, etc., but can be built for other things given enough care for spending the extra effort simplifying the solutions.

The main issue with any discussions on exception is the elephant in the room, Java. Java has a worst model of exception mixing weird typechecking rules + error handling not forcing to recover the exception. I really like the exception model of Erlang, recovery is only possible from another routine. It's is in my opinion the best exception model. Go code is nice because everything is fully explicit but it's hard to re…

>I really like the exception model of Erlang,

Or the exception model of Common Lisp, which is designed for always being able to recover.

Re: Goodbye, Clean Code

#462

Post by bjourne »

JoeyJoJoJr wrote: post #406
TheRealDunkirk wrote: post #294

Earlier quoted context omitted.

Several years ago, I wrote a big chunk of code to analyze engineering data from an engine test cell, and display a graph of the results. Someone else had done the hard part; I was merely coding up a gloriously-complex Excel spreadsheet in C++. I grabbed data from a MySQL database, and labeled the row data like: row[combustion_air_mass_flow] + row[fuel_mass_flow] * row[specific_gravity_of_diesel]. (Or whatever; it's b…

This reminds me when a developer took over my codebase while I was on holiday. When I returned I had discovered that he converted all tab indents to spaces across the entire project. He completely destroyed my ability to perform diffs against earlier commits, because his preference was evidentially more important. Of course this was all justified with a link to Google’s coding style guide.

The commonality in both your and the parent's situation is that you reacted defensively. Your response was "You destroyed my tabs!" when a proper response would have been to try and understand your coworkers motivation. Perhaps he had some really good arguments for preferring spaces over tabs? Tabs can be problematic in heterogeneous environments where developers with different tab settings and different editors work on the same codebase. Have you read the arguments in Google's coding style guideline?

Maybe your coworker was a fucknut that did it just to mess with your code. I wasn't there so I can't know. My point is that you shouldn't assume that.

Re: Goodbye, Clean Code

#463

Post by hota_mazi »

_y5hn wrote: post #444
int_19h wrote: post #147

Earlier quoted context omitted.

"It isn't magic!" mantra is often heard in Go apologetics, but every time I see it, it occurs to me that Go's definition of "magic" is somewhat akin to a 15th century peasant seeing a lightbulb. Stuff like exceptions or error types isn't magic - they have been around for a long time, they're well understood, and they have significant advantages.

Except exceptions are rarely understood and used correctly by most programmers. They can simplify program structure, but at the expense of proper errorhandling and error mitigation strategies. Golang is still in the sort of niche that builds databases, queues, container-orchestration, etc., but can be built for other things given enough care for spending the extra effort simplifying the solutions.

> Except exceptions are rarely understood and used correctly by most programmers

That's pretty condescending.

The mechanism for exceptions has been around for more than 20 years, it is well understood by most programmers.

The problem is that error handling is hard.

Exceptions are an adequately sophisticated solution to that hard problem. Go's approach only encourages ignoring errors (since the compiler never enforces that you handle them) and boiler plate.

Re: Goodbye, Clean Code

#464

Post by hota_mazi »

_old_dude_ wrote: post #458
_y5hn wrote: post #444

Earlier quoted context omitted.

Except exceptions are rarely understood and used correctly by most programmers. They can simplify program structure, but at the expense of proper errorhandling and error mitigation strategies. Golang is still in the sort of niche that builds databases, queues, container-orchestration, etc., but can be built for other things given enough care for spending the extra effort simplifying the solutions.

The main issue with any discussions on exception is the elephant in the room, Java. Java has a worst model of exception mixing weird typechecking rules + error handling not forcing to recover the exception. I really like the exception model of Erlang, recovery is only possible from another routine. It's is in my opinion the best exception model. Go code is nice because everything is fully explicit but it's hard to re…

> Java has a worst model of exception mixing weird typechecking rules + error handling not forcing to recover the exception.

Unless you have a specific complaint about Java's model (which I'd love to read), I strongly suspect that your beef is with a few standard Java library functions misusing checked exceptions than a statement against exceptions in general.

The combination of runtime and checked exceptions offers the most complete solution to the difficult problem of handling errors, with the compiler guaranteeing that error paths are always handled.

Re: Goodbye, Clean Code

#465

Post by scarface74 »

bcrosby95 wrote: post #276
Stratoscope wrote: post #262

Earlier quoted context omitted.

The Rule of 3 is a great rule, except when it isn't. I had a colleague some time ago who wrote a couple of data importers for FAA airspace boundaries. There were two data feeds we cared about, "class airspace" and "special use airspace". These airspace feeds have nearly identical formats, with altitudes, detailed boundary definitions, and such. There are a few minor differences between the two, for example different…

The rule of 3 usually is in reference to small scoped abstractions, not whole modules or subsystems. We're talking about extracting a short function, not significant and potentially thorny chunks of code. But I guess no one explicitly spells this out, so I could see where someone could become confused.

The rule of 3 usually is in reference to small scoped abstractions, not whole modules or subsystems. We're talking about extracting a short function, not significant and potentially thorny chunks of code.

I would say it’s for entire features sometimes. For instance, we are a B2B company. We have features on the roadmap or a feature might be suggested by a client. Either way, you hit the jackpot if you can get one client to pay for a feature that doesn’t exist in your product that you can then sell to other clients.

The problem is that you don’t know whether the feature is generally useful to the market. But you think it might be, in that case, you build the feature in a way that is useful to the paying client and try not to do obvious things that are client specific. But until you have other clients you don’t know.

Re: Goodbye, Clean Code

#466

Post by fredmorcos »

marcus_holmes wrote: post #395
int_19h wrote: post #147

Earlier quoted context omitted.

"It isn't magic!" mantra is often heard in Go apologetics, but every time I see it, it occurs to me that Go's definition of "magic" is somewhat akin to a 15th century peasant seeing a lightbulb. Stuff like exceptions or error types isn't magic - they have been around for a long time, they're well understood, and they have significant advantages.

I kinda prefer this to the Rust apologetics, where every post about Go is replied to with three posts about how Rust does it so much better ;) I've used lots of other languages, as have a lot of other Gophers. I'm not saying "Go's approach is good" out of some strange tribalism or a need to assert my preference. I'm saying this because, having spent over 35 years programming, I really appreciate the simplicity of Go…

A garbage collector of obviously lack of magic.

Re: Goodbye, Clean Code

#467

Post by BoiledCabbage »

klyonrad wrote: post #448
BalinKing wrote: post #288

Earlier quoted context omitted.

Sandi Metz's blog (and book) are an absolute gold mine. I'm a junior developer ( If there was a required reading list for professional developers, I would put her work on with zero hesitation, I feel it to be that important.

You call devs Junior until they have over 5 years experience? Wow, that’s harsh

> You call devs Junior until they have over 5 years experience? Wow, that’s harsh

Less than 3-4 years is absolutely junior dev. Up until around 7 or 8 years is mid-level. Passing beyond that would be senior dev and the other titles then follow.

With the obvious note that it's not strictly time bound - someone could easily get stuck at mid level for much longer if they aren't progressing. It's pretty hard to still be only junior after 7+ years

Re: Goodbye, Clean Code

#468

Post by BubRoss »

StevenWaterman wrote: post #430
BubRoss wrote: post #120

Earlier quoted context omitted.

One big way I prevent this from happening is to treat classes as interfaces to data structures and keep everything that isn't about accessing the data elsewhere. Conversions to other data types go somewhere else. In fact I don't want my data types depending on any other data types at all. When doing this any of this repetition or evolution can stay out of the data structures themselves so that they can be reused with…

Have you not simply abandoned OOP at that point? A core point of OOP is that objects manage their own state, and provide an interface for accessing/mutating it. If classes are only used as data structures, and everything is done through (presumably pure) utility methods, it sounds like you're writing procedural code in an OOP language. That's not inherently a bad thing, but OOP provides benefits and you may be making…

I try to worry much more about what works rather than labels.

If you stuff all your functionality and data transformations into class definitions, your class definitions will be full of dependencies. Now all the fundamental elements of your program depend on each other and can't be separated.

It's like trying to pile up concrete until it forms a cave instead of laying it down to make the floor and building on top of it.

What am I missing?

Re: Goodbye, Clean Code

#469

Post by datavirtue »

klyonrad wrote: post #448
BalinKing wrote: post #288

Earlier quoted context omitted.

Sandi Metz's blog (and book) are an absolute gold mine. I'm a junior developer ( If there was a required reading list for professional developers, I would put her work on with zero hesitation, I feel it to be that important.

You call devs Junior until they have over 5 years experience? Wow, that’s harsh

Ten years. Minimum. I don't trust anyone without gray hair. That includes me and I have twenty years.

Re: Goodbye, Clean Code

#470

Post by luord »

> Let clean code guide you. Then let it go.

Nah, no offense to the react fans but I'd rather listen to Fowler than to this guy.

Sure, there are very specific exceptions where repeated code is an asset instead of a liability (and many of them are, appropriately enough, when dealing with graphics), but they are that: very specific. For 99% of situations, we ought to follow the principles (obligatory IMO).

Post reply on HN