HN Theater @HNTheaterMonth

The conclusions are similar to what I've seen in this talk by Kevlin Hennley: https://www.youtube.com/watch?v=ZsHMHukIlJY

And I think they are pretty reasonable.

I've used camelCase a lot but I am about to switch to the good old underscore_style as it really might be easier to read.

And there is no doubt in my mind that alignment, spacing and structure is almost as important as good naming.

And of course, Allman style braces.

⬐ timw4mail

I have yet to see a good case for alignment over indent-wrapping.

For example, if there is a map of object properties that is ~20 or so items long, with an alignment of each value you cut down on the jaggedness of each line. I see that jaggedness as an advantage, where each line is slightly more unique, and thus easier to scan in context. Additionally, the key on the front of the line is generally what you are searching for, so alignment generally does nothing for searchability anyway.

⬐ kbenson

While Allman style can be very pleasing, it requires the right language, as certain language features will make it off putting to see it used in some places in not others. For things like C, it makes sense. For languages that use braces for blocks inline (e.g. Perl), you're going to constantly have a mix of Allman style braces and inline/infix braces if you use the language features in a useful manner.

Put another way, style is something that should be chosen per language, perhaps with very similar languages having a style that it makes sense for you to share across them. A blind adherence to any specific style across languages is not necessarily useful. This is obvious when you consider languages as disparate as C, Lisp and APL, but it applies similarly, if more subtly, to languages that aren't nearly as different as those are from each other at first glance.

Kevlin henney has a lot to say about concurrent processing ithink it was one of thesr talks:

https://youtu.be/2yXtZ8x7TXw

https://youtu.be/ZsHMHukIlJY

Threading is faster, but really only if youre willing to give up your locks and design for it properly.

Disagree. There's value in consistency, even for the shallow matter of formatting. There's a reason so many large-scale software-development companies care about coding standards.

You're right that it's not a matter of there being one true style. I agree with Kevlin Henney though that there are certainly wrong ways to format code - https://youtu.be/ZsHMHukIlJY?t=1027

Some food for thought: https://youtu.be/ZsHMHukIlJY?t=633

For example, this is the best way to define functions with argument lists long enough not to fit on a single line:

  fn doThing(
      argument1,
      argument2,
      argument3,
  ) {
      <code>
  }

Visually clear, doesn't have any spaces/tabs issues, produces minimal diffs when adding/removing/renaming arguments.

⬐ Stratoscope

Very interesting talk! Thanks for the reference.

More food for thought:

The style in your example is more consistent with the way nearly every programmer formats code that has more than one statement. For example:

  if( shouldDoThings ) {
      doOneThing();
      doAnotherThing();
      doLastThing();
  }

Why do we want to format statements that way, but function calls and expressions a different way? No one would write this:

  if (shouldDoThings) {doOneThing();
                       doAnotherThing();
                       doLastThing();}

I have a theory about that but will have to save it for another day.

Somewhat related, the Rust coding style guidelines used to follow a heavily column-aligned style, but changed to indentation-only a year or two ago. I posted an example from the Servo source code with the old and new formats here:

https://news.ycombinator.com/item?id=18962177

First of all, thanks for sharing; it's a very educational piece of code!

I have some generic coding advice though. With slightly better names you can get rid of a lot of the comments. There is a lot of repetition in the code. If you factor that out, you will have even less need for comments. I highly recommend watching some Kevlin Henney talks on such topics, for example https://youtu.be/ZsHMHukIlJY?t=487 (but he has even better talks recently)

The input of the program should be supplied in a more format more natural to humans and let the computer do the transformation into whatever data structure it's comfortable with. So I would propose a simple, multi-line text as an input:

    xxxxxx
    0x000x
    x*0x0x
    xxxx00
    00000x
    xxxx0x

Then the code would look like this:

    (ns maze.solver
        (:require [clojure.string :as str]))

    (def maze-filename "maze.txt")

    (defn parse [maze-str]
     (->> maze-str
          str/trim 
          str/split-lines
          (mapv (partial into []))))

    (def maze (-> maze-filename slurp parse))

You can also just hardwire a maze during development into the source file, since Clojure supports multiline strings:

    (def maze (parse "
    xxxxxx
    0x000x
    x*0x0x
    xxxx00
    00000x
    xxxx0x
    "))

The result of `parse` function will contain character data types instead of 1 character long strings. I think in this case it's actually more readable and more concise too:

    [[\x \x \x \x \x \x]
     [\0 \x \0 \0 \0 \x]
     [\x \* \0 \x \0 \x]
     [\x \x \x \x \0 \0]
     [\0 \0 \0 \0 \0 \x]
     [\x \x \x \x \0 \x]]

Next `println` actually accepts multiple arguments and concatenates them with a space, after stringifying them, so you can drop the extra `(str ...)` wrapping around them.

Then again, the comment is superfluous. It's obvious that you are printing stuff. If you really want to tell what is it, just wrap it in a well-named function. Eg:

    (defn report [paths]
      (println "The maze has" (count paths) "paths.")
      (println "The shortest path in the maze is:" (count (first paths)) "steps long.")
      (println "The path is" (first paths))
      (println "The longest path in the maze is:" (count (last paths)) "steps long.")
      (println "The path is" (last paths)))

So you can just put `(report sorted-paths)` in your `-main`.

⬐ netb258

I am shamelessly stealing your code.

⬐ Piskvorrr

#0: encoding what is, in essence, an essay, into video - to be viewed precisely at author's pace. Is there a transcript?