Hacker News Reader

Comment by calafrax | Hacker News Reader

> if you need more than 3 levels of indentation, you’re screwed anyway, and should fix your program.

I hope some JS programmers read this

I think it is a bad idea to apply that rule to all programming languages though. If you are doing Java, for example, and have a function inside of a class, and a loop in the function, putting a condition inside of the loop would violate the rule, and that is a pretty common thing to do.

Consider it from a base level rather than indent 0, and it will work for Java.

The kernel guideline doesn't mention this due to being C specific. C++ can exhibit similar issues.

Early returns ftw (if (!cond) return; instead of if(cond) do();)!

several indentations in js is most of the time linear async flow, while in other languages it usually means branching complexity. while an experienced js programmer can deal with async code and avoid the so called callback hell, nesting the callback doesnt make it any harder to understand, just harder to test, debug and refactor.

I referenced this quote when my team was bikeshedding over our linting configuration, and I was pushing for a lower line limit.

Why are anonymous functions so popular in JS? Why not just name the callback?

Because Java is a kingdom of nouns, and for the most part (method handles, which are just fancy reflection objects, aside), you can't name a function without creating a closure.

Anonymous callback:

  Foo.foo(() -> bar());

Named callback:

  private final class MyFooDelegate implements FooDelegate {
    @Override
    public void doFoo() {
      bar();
    }
  }

  ...

  Foo.foo(new MyFooDelegate())

You forgotten about method handles.

Why name it if the name will never be used?

The name shows up in the stack trace, and you'll have a much better idea which path the code hit when it crashed.

naming things are hard and some programmers are willing to sacrifice their left hand if it means they can write shorter syntax.

async/await to the rescue!

functions and closures to the rescue

The first professor who I took a programming class from told us that anytime we needed to indent something we should be asking ourselves if we needed to create a new function and most times the answer would be yes.

It was good advice.

If your function is only called once it's better to leave it indented than to create a function.

Depends on the context/language I think. Splitting a block of code into a function gives it a greppable name that (ideally) succinctly describes the point of the block. You can have that block just headed by a comment inline to try and do the same thing, but comments are extremely prone to getting ignored and left to grow outdated when the purpose of the code around them changes. It's easier for the reader to just mentally abstract away that block if it's separated into a function. And if that block is worth testing, it's much easier to do when it's isolated into its own function.

There's reasons to keep the block inline too--like if you're working in a more resource constrained environment, or if the block isn't really isolated/self-contained enough to cleanly abstract away, or if the block in question isn't really doing anything substantial. But I wouldn't say that you should only abstract away code into functions to save yourself from literally copy/pasting the lines in multiple places.

You could argue that it's better to make the function; the compiler will probably inline it if it's only used once, and it helps avoid having the logic duplicated if it's needed again (or by lazy copy/paste programmers).

My point is not performance but that a function used only once is likely just contributing to one conceptual block of code. But now it's artificially divided up and one has to jump around to understand that code as a whole. There are exceptions of course but blindly adding functions to avoid indenting is probably going to lead to a harder to follow solution.

in js you can just leave the named function inline. i sometimes create functions that call themself so that i can just move it out if the code needs to be repeated, and i dont have to clutter the scope with more variables. with es6 js got bracket scoping, but i still prefer function scope and closures.

Reply on news.ycombinator.com