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

591–599 of 599 posts

Re: Goodbye, Clean Code

#591

Post by jariel »

paulnechifor wrote: post #529
Rapzid wrote: post #102

Earlier quoted context omitted.

I'm a native English speaker and found absolutely nothing unusual about the grammar in the article. Do you have any specific examples?

One example: > My boss invited me for a one-on-one chat where they politely asked me to revert my change. I was aghast. The old code was a mess, and mine was clean! I begrudginly complied, but it took me years to see they were right. The first they sounds like the boss and the colleague were in the same room, but it can't because he says one-on-one. Still, presumably both the boss and the colleague wanted the revert.…

It's the boss and it's grammatically clear.

It's a tiny bit odd, but not really actually.

'They' is totally fine in this case.

Re: Goodbye, Clean Code

#592

Post by collyw »

burlesona wrote: post #10

I’ve usually heard this phenomenon called “incidental duplication,” and it’s something I find myself teaching junior engineers about quite often. There are a lot of situations where 3-5 lines of many methods follow basically the same pattern, and it can be aggravating to look at. “Don’t repeat yourself!” Right? So you try to extract that boilerplate into a method, and it’s fine until the very next change. Then you ne…

I am coming to the conclusion that code reuse is over pushed as an ideal in universities. Often the desire to create reusable code means that we create overly complicated code with less duplication.

Re: Goodbye, Clean Code

#593

Post by scarface74 »

dkersten wrote: post #522
kazinator wrote: post #485

Earlier quoted context omitted.

The repetition is what is YAGNI! Repeating code 7 times in preparation for separate evolution of those 7 cases is YAGNI, unless the requirements are on the table now. Merging repeated code into one is something that is demonstrably needed now, not later.

Yes, I agree. That’s not what I was replying to, though. I noted in another comment that I consider merging worthwhile even in the absence of three use cases, certainly if what you have now is very similar.

If all seven are the same except for one or two cases, it doesn’t mean that you have to have a bunch of if statements, you either use inheritance or composition to create special cases and judiciously apply “pull members up” and “push members down” refactoring, interfaces, abstract classes, virtual methods, etc. These are all solved problems.

Yes I know about the whole “a square is not a rectangle problem”.

Re: Goodbye, Clean Code

#594

Post by scarface74 »

DonHopkins wrote: post #329
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…

Oliver Steele describes "Instance First Development", which the language he designed, OpenLaszlo, supported through the "Instance Substitution Principle". I've written about it here before, and here are some links and excerpts. https://news.ycombinator.com/item?id=14418108 In the right context, prototypes can enable Instance-First Development, which is a very powerful technique that allows you to quickly and iterativ…

In OpenLaszlo, you can create trees of nested instances with XML tags, and when you define a class, its name becomes an XML tag you can use to create instances of that class. That lets you create your own domain specific declarative XML languages for creating and configuring objects (using constraint expressions and XML data binding, which makes it very powerful).

This gives me nightmares of over engineered xml programming that is infamous I the Java community. You lose all of the benefits of static type checking.

Re: Goodbye, Clean Code

#595

Post by mluds »

The author seems to only look at a narrow case that supports his argument. Imagine you start out with 2 shapes and 4 directions, but you eventually get additional requirements for 20 more shapes and 4 more directions. Now you have much more code, introducing room for errors, making it harder to change, and making it harder for new employees to understand.

I agree that he should have told his coworker ahead of time, but I also think his coworker should be open to understanding why his code may cause problems and be ok with it being changed.

Re: Goodbye, Clean Code

#596

Post by therealdrag0 »

babarock wrote: post #114
burlesona wrote: post #10

I’ve usually heard this phenomenon called “incidental duplication,” and it’s something I find myself teaching junior engineers about quite often. There are a lot of situations where 3-5 lines of many methods follow basically the same pattern, and it can be aggravating to look at. “Don’t repeat yourself!” Right? So you try to extract that boilerplate into a method, and it’s fine until the very next change. Then you ne…

One of the areas where I really like "incidental duplication" is in tests. Tests can sometimes be very repetitive and identical, and it's tempting to want to refactor it in some clever way. That's almost never good. On top of the reasons laid out in parent comment, tests also function as unofficial documentation. I like having everything explicit in there, it makes them easier to read and understand.

I'm not sure I agree. I like to move all setup code to helper methods so that my tests are just a few lines

  // Given 
  
  // When 

  // Expect  to be
This allows the reader to easily see which workflows are actually tested. If the reader is interested in implementations the utility code is one click away and usually only needs to be looked at once to be completely understood. The test bodies themselves however have many flavors for many work-flows so getting rid of the repetition is critical to highlight the specific nature of individual tests.

Re: Goodbye, Clean Code

#597

Post by therealdrag0 »

dx034 wrote: post #562
quickthrower2 wrote: post #273

Earlier quoted context omitted.

When you work with your own apps you can be as messy as you like. In a team there is some incentive to make the code readable to other developers. At the lightweight end you have coding standards and linting, then design patterns then finally big refactorings. It’s all trade offs. Bug team products can have islands of code that are like one person projects and those can be messy for example.

Code with duplications isn't less readable. Quite the opposite. Fighting your way through layers of abstractions and generalizations can make it harder to understand for someone new to the code. Especially code that will rarely be touched except for bug fixes, having it as simple as possible can often be worth it. And in the end, users will also appreciate this. Any time spent refactoring is time not spent on new fea…

It's gotta be case-by case, but upon shallow reflection I feel like 1 layer of abstraction is the sweet spot. I've worked on code where I have to "Go-to definition" a dozen times to figure out what is going on, and I hate it. And I have seen code where it's just a big wall of text hundreds or thousands of lines long, and I hate it.

Re: Goodbye, Clean Code

#598

Post by adamisom »

crimsonalucard wrote: post #182
adamisom wrote: post #6

Earlier quoted context omitted.

Would it help to point out the the author of that post invented React?

When in doubt refer to authority over logic. Authority wins every time.

It wasn't worth deconstructing their "logic". Rather, my implicit message was 'if you find yourself disagreeing with someone likely better than you at X, step back and assess the epistemic foundations of _your_ belief.'

Re: Goodbye, Clean Code

#599

Post by jgwil2 »

kazinator wrote: post #495
_y5hn wrote: post #481

Earlier quoted context omitted.

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 wil…

If it was Python then it would be highly unlikely to have used tabs in the first place.
Post reply on HN