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

Avoid Else, Return Early (2013)

blog.timoxley.com

Post reply on HN
Print view View original

571–580 of 601 posts

Re: Avoid Else, Return Early (2013)

#571

Post by yitchelle »

koolba wrote: post #95
drawkbox wrote: post #65

Programmers with lots of hours of maintaining code eventually evolve to return early, sorting exit conditions at top and meat of the methods at the bottom. Same way you evolve out of one liners. Same way comments are extra weight that should only be in public or algorithm/need to know areas. Same way braces go on the end of the method/class name to reduce LOC. Same way you move on from heavy OO to dicts/lists. Same w…

> Same way you get joy deleting large swaths of code. This is the true sign of a programmer's transcendence. Specifically the irrational joy of seeing net negative LOC diffs. It's not about how much you can add. It's about how much you can remove without sacrificing correctness, functionality, and readability.

The less code there is, there less opportunity there is for bugs.

Re: Avoid Else, Return Early (2013)

#572

Post by boomlinde »

drawkbox wrote: post #65

Programmers with lots of hours of maintaining code eventually evolve to return early, sorting exit conditions at top and meat of the methods at the bottom. Same way you evolve out of one liners. Same way comments are extra weight that should only be in public or algorithm/need to know areas. Same way braces go on the end of the method/class name to reduce LOC. Same way you move on from heavy OO to dicts/lists. Same w…

My experience, on the contrary, has left me thinking that none of these are absolute. You apply certain constructs and styles where they make sense—which depends on what you're writing and who you're writing it with—and become increasingly suspicious that people who appeal to absolutes simply haven't yet encountered situations where the trade-offs ultimately balanced out in favor.

Re: Avoid Else, Return Early (2013)

#573

Post by boomlinde »

brianpan wrote: post #494
xg15 wrote: post #465

Earlier quoted context omitted.

> Same way you move on from heavy OO to dicts/lists. Is that a thing? No question that many concepts of OOP are in heavy need of reform, but I didn't know the basic idea of a struct was one of them. I can sort of imagine this for quick-and-dirty things in untyped languages - but if you have types, passing dicts around everywhere seems like needlessly throwing away type safety - while it's also cumbersome to code and…

I think this might partially be related to the move towards streaming applications and microservices. You could create objects for everything you expect to receive/send and then when an API changes you lose the new fields, you get parse errors, etc. If you did it right maybe you can avoid some of those things, but the bottom line is that type safety is a little bit too strong a constraint for these use cases. Even if…

You can of course create a User and a UserDetails, the former embedding the latter when necessary.

I also see getting parse errors when APIs change as a positive thing. When you change an API, things do break. Learning what breaks as early as possible is good. It's not even about objects vs. dictionaries, you could use any structured composite datatype and the overhead you associate with it depends very much on the language.

Of course, for a quick hack I'd happily dump data into a dictionary and call it a day. But if I want to learn why it breaks 5 years later, having a clear specification of the expected data is much better even if it cost me an extra few hours.

Re: Avoid Else, Return Early (2013)

#574

Post by [deleted] »

cestith wrote: post #415
always_good wrote: post #391

Earlier quoted context omitted.

I'd say it's the opposite. Code formatters are winning. It's becoming increasingly trite to bikeshed over formatting when projects are using code formatters.

As Andy Lester recently tweeted (but said it wan't his): Should "bikeshedding" be hyphenated? I should see if he remembers where he got it.

[deleted]

Re: Avoid Else, Return Early (2013)

#575

Post by petdance »

cestith wrote: post #415
always_good wrote: post #391

Earlier quoted context omitted.

I'd say it's the opposite. Code formatters are winning. It's becoming increasingly trite to bikeshed over formatting when projects are using code formatters.

As Andy Lester recently tweeted (but said it wan't his): Should "bikeshedding" be hyphenated? I should see if he remembers where he got it.

I don't know. If I remembered I'd have attributed it. I noted that it wasn't mine as the next-best-thing.

Re: Avoid Else, Return Early (2013)

#576

Post by spiralx »

dorgo wrote: post #531
okbake wrote: post #521

Earlier quoted context omitted.

I'm a fan of TypeScript's structural typing for this reason. I can define an interface that describes the shape of a "plain old object" (it's fields and their types), and then write functions that accept/returns an object of that interface. What's great about structural typing is I don't have to explicitly say "create a new object of this type", any object that satisfies the shape of the interface is valid (object li…

Don't you get problems with equal Signatures but different meaning or different scale? Example: interface SomethingWithAge{ age(); } class Person{ age(); // age in years } function classify( SomethingWithAge item ){ if( item.age() p = new Person( 33 ); classify( p ) // prints 'old' class Message{ age(); // age in milliseconds } c = new Message( 231443 ); classify( c ); // prints 'old'

https://github.com/Microsoft/TypeScript/issues/202

It's in the roadmap, but discussions about it are still going on four years after the ticket was opened...

Re: Avoid Else, Return Early (2013)

#577

Post by boomlinde »

weinzierl wrote: post #200
drawkbox wrote: post #65

Programmers with lots of hours of maintaining code eventually evolve to return early, sorting exit conditions at top and meat of the methods at the bottom. Same way you evolve out of one liners. Same way comments are extra weight that should only be in public or algorithm/need to know areas. Same way braces go on the end of the method/class name to reduce LOC. Same way you move on from heavy OO to dicts/lists. Same w…

> Programmers with lots of hours of maintaining code eventually evolve to return early, [..] I agree with all your other points and I‘d even agree if you wrote return early makes code more readable but not that it‘s something experienced programmers do. Programming is still - to some degree - resource management. Inexperienced devs often miss that fact, because they are focused on memory management and believe they c…

I frequently use `goto` in C for this reason. A very common pattern is that I acquire some resources, do something with them, and have a section at the end of the function where I release them in LIFO order. This is labeled so that failure to acquire any resource will jump to a label just before the resources that were acquired before it are freed.

Other languages have constructs that obviates this pattern, for example Python has `with` blocks that acquire resources and free them upon leaving the block, and Go has a `defer` statement which adds code to some LIFO structure that always gets executed upon returning.

Re: Avoid Else, Return Early (2013)

#578

Post by boomlinde »

optimuspaul wrote: post #111
Merad wrote: post #106

Earlier quoted context omitted.

> Same way braces go on the end of the method/class name to reduce LOC. Screw that. I've been writing code for 15 years, and Allman style braces make it so much easier to mentally parse code into blocks that they're worth every single LOC. I can't speak for anyone else but I'm not working on an 80x24 terminal anymore.

Totally disagree with you.... it's funny though that I read LOC as "level of complexity" not "lines of code". I've been writing code for 30 years and I think it's jarring when the braces are on the next line, so much easier for me to parse that when it's on the same line. But everyone is entitled to their own opinion.

The level of complexity obviously doesn't change with a line break

Re: Avoid Else, Return Early (2013)

#579

Post by klmr »

monocasa wrote: post #360
klmr wrote: post #338

Earlier quoted context omitted.

`finally`/RAII doesn’t depend on checked exceptions. It always runs (short of something that aborts the program without unwinding the call stack; and in those cases single-exit won’t save you).

Mixing finally and RAII into the same category doesn't really make sense here. And I'm not saying that finally depends on checked exceptions, I'm saying that pattern is very brittle. You change lower code to throw a new exception, and you change the above code to catch it like you're supposed to, but now the middle code has no idea that there's this new exception and leaks resources. So you end up either having britt…

> middle code has no idea that there's this new exception and leaks resources

You misunderstand how `finally` works. The whole point is that it runs regardless of exception type. So the resulting code in the middle layer doesn’t need to know anything about the code it calls, and doesn’t leak resources, even when calling or called code changes: It’s not brittle.

> or you're wrapping pretty much all function bodies with try-catch-finally-rethrow.

No need for `catch` and rethrowing. And in the case of C# and modern Java, no need for the rest either: You only need to wrap resources that you allocate into `using` (C#) or `try` (Java; but not `try…finally`! [1]). Sure, it’s more verbose than RAII in other languages with automatic storage duration (like C++). But it effectively performs the same.

[1] https://docs.oracle.com/javase/tutorial/essential/exceptions...

Re: Avoid Else, Return Early (2013)

#580

Post by vk23 »

usrusr wrote: post #307
ajuc wrote: post #158

Earlier quoted context omitted.

There's no alternative for healthcare. There's alternative to in-code comments answering the question "why" - it's commit messages. They can't be out of date.

But commit messages can easily get plowed under in some annoying "reformatted, I hate tabs/spaces" commit. I do like to see some "why" sprinkled in here and there that will survive those accidents. But I will nonetheless prefer blame output if it is still meaningful. Also, I enjoy a commit that removes redundant comments almost as much as one that removes redundant code.

You can either pass a commit id to git blame to see changes before the reformat happend or you can use git log like this:

git log -L0,10:file.txt

Post reply on HN