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

481–490 of 601 posts

Re: Avoid Else, Return Early (2013)

#481

Post by khedoros1 »

djsumdog wrote: post #143
fouc wrote: post #119

Earlier quoted context omitted.

Only "brilliant" code ends up needing comments. Plain code organized into understandable methods (usually no more than half a page of code), with good naming for variables & method names reduces the need for comments. It's also easier to scan/read code if there's a minimum of comments in the way.

I agree with this. When dealing with a modern programming language, it's just easier to name your functions and variables in such as way that they're readable. It makes sense to document public functions using the language's documentation syntax, if you're writing an API. I look back at a lot of my old code and even without comments, it's easy to follow the logic because I used sensible names and constructs.

Good, clear code, with nice names and such shows what the code is doing and how it's doing it. It doesn't tell you anything about why it's being done, or the context of the function within the code.

You're lucky if you're dealing with code that's either small enough or simple enough not to need the added context...or if you only need to read your old code.

Re: Avoid Else, Return Early (2013)

#482

Post by dv_dt »

DonaldPShimoda wrote: post #408
tren wrote: post #156

Earlier quoted context omitted.

"Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away."

This is my favorite research quote from a Civilization game (Civ IV, narrated by Leonard Nimoy). I use this as my mantra for all design-oriented aspects of my life now. Or... I try to. Sometimes it's hard not to want to add more haha.

FYI that quote is from Antoine de Saint-Exupry, author (and pilot) famous for "The Little Prince".

Re: Avoid Else, Return Early (2013)

#484

Post by edejong »

loup-vaillant wrote: post #214
Turing_Machine wrote: post #139

Earlier quoted context omitted.

"this... to reduce LOC ? Doesn't feel like a valid reason in any language using braces..." It's not really a valid reason. Unfortunately, there are still a lot of people who think LOC is a valid metric.

Here's an extreme, yet very real example: mandatory Doxygen comments on accessors: /** * Get the foo * * @return the foo */ int getFoo(); /** * Get the bar * * @return the bar */ float getBar(); /** * Set the foo * * @param foo the foo */ void setFoo(int foo); /** * Set the bar * * @param bar the bar */ void setBar(float bar); Compare with what any sane project would do: int getFoo(); float getBar(); void setFoo(int…

Or you use scala:

case class Baz(foo: Int, bar: Float)

Gives you a free hashCode, equals and copy as well.

Re: Avoid Else, Return Early (2013)

#485

Post by z3t4 »

Bombthecat wrote: post #445
optimuspaul wrote: post #111

Earlier quoted context omitted.

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.

I remember in my programming classes at school my teacher was always like: guys!there is space on the right! Use it! PS: he coded at Hercules the graphic cards back in the day before he got into teaching.

What is "Hercules the graphic cards" (I only found GPU's when trying Google)

Re: Avoid Else, Return Early (2013)

#486

Post by monocasa »

jstimpfle wrote: post #464
monocasa wrote: post #395

Earlier quoted context omitted.

RAII works just as well for heap allocated objects as it does for stack allocated ones.

Sure, but allocating resources on the stack is not good for maintainability. Software is easier to understand if its state is not hidden in semi-permanent call stack frames.

In general I agree with you, but that seems orthogonal to the subject at hand.

Re: Avoid Else, Return Early (2013)

#487

Post by jstimpfle »

monocasa wrote: post #342
jstimpfle wrote: post #320

Earlier quoted context omitted.

Downside is, now your cleanup code is spilled all over the codebase. And where it's implemented it lacks often the necessary context (from the location of use). So, it's often wrong or incomplete, or suffers from the type-for-single-usage syndrome. Yes, RAII works for the casual std::vector, but it's not a maintainable solution for general resources.

It's right next to the create code, not 'spilled all over the codebase'. And if you really want different behavior on destruction (which is _really_ rare IMO), you can pass a destruction strategy at object construction. If you don't know how you want to destroy something when you construct it, you need to take a step back and reexamine your architecture.

And the create code is spilled over the codebase, just as well :-). It's not where actual work is done. This approach of encapsulating functionality in a class may work in some instances such as std::vector but more often than not it's just a lot of (typical OOP) boilerplate for things that you do only once in a codebase anyway. Giving one-off things a type and a name and decoupling them from normal control flow (ripping them out of context) makes things just harder to understand. Better just make them global data, maybe even define the initialization/cleanup routines for that global data in-line with the rest of the control flow.

Re: Avoid Else, Return Early (2013)

#488

Post by tabbspace »

YSFEJ4SWJUVU6 wrote: post #350
tabbspace wrote: post #336

Earlier quoted context omitted.

Until you need spacing that isn’t a multiple of your tab width then you’re screwed.

Why would you ever half-indent a block? For alignment you should of course use spaces (for whole alignment, not just the end, to be very clear).

Lining up arguments across multiple lines sometimes involves non-multiples of tabs.

Re: Avoid Else, Return Early (2013)

#489

Post by z3t4 »

falcolas wrote: post #208
kstenerud wrote: post #167

Earlier quoted context omitted.

I've done a number of informal tests on friends and family over the years regarding brace placement, and it's always been the same: For someone with NO experience programming (i.e. looking at what to them seems like a bunch of gobbletygoop - and what's a "text editor"?), adjacent braces make it appear more readable than same-line braces. It's only people who cut their teeth on adjacent bracing that find it more reada…

Why optimize for the lowest common denominator? I've seen both, and the reduction in vertical whitespace matters more to me than the readability to an untrained individual.

Tip: Tilt your wide screen so you get more vertical real estate.

Re: Avoid Else, Return Early (2013)

#490

Post by jimmaswell »

rawoke083600 wrote: post #176
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 comments are extra weight that should only be in public or algorithm/need to know areas. " Best thing I learned about commenting is: Comment WHY you are doing it... not WHAT. Code is the WHAT... Comment is the WHY

If you feel the need to specify in a comment that the code does some potentially unexpected thing or that the way it does what it does has certain consequences, that's fine. And obviously the comment/doc of a function/class/whatever should say what it does if it's not 100% obvious and unambiguous from the name. I don't think this kind of rule is really helpful. Just comment if you feel a comment is needed, and if other people who interact with your code think you have too many or too few comments then you can adjust from there.
Post reply on HN