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

491–500 of 599 posts

Re: Goodbye, Clean Code

#491

Post by kazinator »

TheRealDunkirk wrote: post #294
bjourne wrote: post #274

> Firstly, I didn’t talk to the person who wrote it. I rewrote the code and checked it in without their input. Even if it was an improvement (which I don’t believe anymore), this is a terrible way to go about it. A healthy engineering team is constantly building trust. Rewriting your teammate’s code without a discussion is a huge blow to your ability to effectively collaborate on a codebase together. I totally disagr…

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…

Replacing symbols with meaningless numbers is almost absolutely unjustifiable outside of the job description of a compiler.

Re: Goodbye, Clean Code

#492

Post by [deleted] »

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.

[deleted]

Re: Goodbye, Clean Code

#493

Post by aj7 »

Stratoscope wrote: post #262
scarface74 wrote: post #25

Earlier quoted context omitted.

That can be boiled down to the “Rule of 3”. My CTO often asks me to implement a feature to do X and make it “generic enough to handle future use cases”. My answer is always the same - either give me at least three use cases now or I am going to make it work with this one use case. If we have another client that needs the feature in the future then we will revisit it. Of course, there are some features that we know in…

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…

There’s a safety issue here. I can conceive of these code blocks diverging more with time. Plus is there really a cost of duplication.

Re: Goodbye, Clean Code

#494

Post by aj7 »

pvorb wrote: post #346
valand wrote: post #311

Earlier quoted context omitted.

Premature abstraction. Rule of 3 helps. But I found better principle for it: Any abstraction MUST be designed to be as close as possible to be language-primitive-like. Language primitives are reliable, predictable, and non-breaking. If they do, they don't affect business logic written on top of it. If parameters are added, defaults are provided. They don't just abstract, they enable developers to express business log…

I find abstractable parts in code by thinking about potential names for it. If there is no good name for a potential common function, it's probably not a good idea to extract the section into a function. Maybe it can be extracted into two separate functions with good names?

Like.

Re: Goodbye, Clean Code

#495

Post by kazinator »

_y5hn wrote: post #481
JoeyJoJoJr wrote: post #406

Earlier quoted context omitted.

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.

It destroyed your ability to exclude whitespace from diffs?

If this happened to be Python, there is no such thing. Two pieces of Python code that have different semantics can look identical under a whitespace-excluding diff, so you must not habitually use such a thing as your go-to comparison method.

For instance if we edit:

   if condition:                     if condition:
     blah                              blah
     blah                   ->       blah
     blah                            blah
then nothing shows under "diff -b" or "diff -w". With a different kind of language there will be a non-white-space difference due to the changing position of a brace or other delimiting token.

Otherwise, exactly the remark I was thinking of making.

Re: Goodbye, Clean Code

#496

Post by TravHatesMe »

gameswithgo wrote: post #433
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…

Every single rule or advice in programming is good until it isn't. OOP is good until it isn't, function programming is good until it isn't, premature optimization is the root of all evil until it is the root of all good. For some reasons humans have this deep need to try and boil things down to bulleted lists which in the domain of programming are just incredibly not useful.

I think that you have a point but I often find myself citing guidelines or rules when I am evaluating code decisions or questioning code design. Maybe it depends on your interpretation of the phrases, some sayings should be followed religiously but others applied with discretion.

Re: Goodbye, Clean Code

#497

Post by _y5hn »

hota_mazi wrote: post #464
_old_dude_ wrote: post #458

Earlier quoted context omitted.

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…

Sounds nice, and of course it is possible to build solutions with exceptions that do recover all errors elegantly and cleanly. However, the correct judge on this would be your own users. Given enough care, the discussion becomes rather philosophical.

Though, having to confront errors through the callstack makes one review where handling would be most prudent, in real-life the time-pressures are just too strong making such efforts largely unrewarded.

Re: Goodbye, Clean Code

#498

Post by akoncius »

gameswithgo wrote: post #433
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…

Every single rule or advice in programming is good until it isn't. OOP is good until it isn't, function programming is good until it isn't, premature optimization is the root of all evil until it is the root of all good. For some reasons humans have this deep need to try and boil things down to bulleted lists which in the domain of programming are just incredibly not useful.

well said. for a while I started treating everything as a soft rule, more like guideline. it gets easier then :)

Re: Goodbye, Clean Code

#499

Post by gusmd »

lonelappde wrote: post #211
blazespin wrote: post #142

Earlier quoted context omitted.

Tests rarely have bugs, I find, so generally dry isn’t critical. Also, dry is for security (see below)

Tests have fewer bugs if you write them before the system under test, and if they don't have mocks, and if you have enough of them that anything you get wrong the first time will get noticed by the results of the many similar tests.

> Tests have fewer bugs ... if they don't have mocks

100x this. I've repeatedly fail to convince my team members that mocks are unnecessary in most cases. I've reviewed code with mocks for classes like BigDecimals and built-in arrays. This is especially prevalent in Java teams/codebases.

Drives me insane.

Re: Goodbye, Clean Code

#500

Post by scarface74 »

aj7 wrote: post #490
endgame wrote: post #248

Earlier quoted context omitted.

From (I think) an old Joshua Bloch talk on API design, paraphrased: * If you generalise based on one example, you will get a flexible API that can handle only that example. * If you generalise based on two examples, you will get a flexible API that can switch between those two examples. * If you generalise based on three examples, you have a chance of abstracting over the common essence.

Until an example that “doesn’t fit” ?

And then if the example “doesn’t fit”. It’s by definition a different thing than you originally modeled
Post reply on HN