Hacker News Reader

Comment by goblin89 | Hacker News Reader

Why put logical operator at the start and not the end of each line?

I.e., this style (used in this case)

      && (CONSTANT_P (SUBREG_REG (in))
	  || GET_CODE (SUBREG_REG (in)) == PLUS
	  || strict_low
	  || (((REG_P (SUBREG_REG (in))

versus this style:

      (CONSTANT_P (SUBREG_REG (in)) ||
	  GET_CODE (SUBREG_REG (in)) == PLUS ||
	  strict_low ||
	  (((REG_P (SUBREG_REG (in)) &&

I don't have a personal preference here, just looking for any practical pros and cons I may not be aware of.

More on topic, I don't see why keep such a big conditional and not move it out to its own function(s) (but this has been asked already in this thread).

View on HN

I used to use the latter, in both code and maths, but I have switched to the former. My main reason is that having the operators (logical and otherwise) at the start of the line means they're more likely to be in the same horizontal position, so it's easier to see which lines are continuations of the previous ones.

This, plus the stucture stays very readable even if for any specific reason a test clause has a very long line.

It is also easier to comment out lines of code if you need to test something. This is especially useful in SQL, where you can quickly -- a condition or a column, without editing commas etc on other lines, eg

SELECT

    some_col

    , another_col

    --, and_another

    , and_more

FROM

    blah

EDIT: too bad formatting is screwed up :/

Isn't this behaviour exactly the same as with commas at the end? Here, to comment out the first line you would need to edit the second. With commas at the end, to comment out the last line you would need to edit the second last. Other than that, no editing of other lines is required.

In fact, in a language like Javascript where extra trailing commas are allowed, it seems that this argument makes even more sense for commas at the end than it does for commas at the beginning. Then, there would never be a situation where you would have to edit a line besides the one you were commenting out.

Not if the line you're commenting out is the last item of a select or a join command or an AND within a where clause. Sorry Gould have made better example But it was 4 am :)

Trailing comma in SQL is a syntax error. It's also not allowed in JSON. And editing second last line can be a pain if you're testing something and are commenting/uncommenting the last line repeatedly.

See how they're using #ifdefs? Those work much better with initial operators. Consider:

    ...
		  == NO_REGS))

#ifdef CANNOT_CHANGE_MODE_CLASS || (REG_P (SUBREG_REG (in)) && REGNO (SUBREG_REG (in)) < FIRST_PSEUDO_REGISTER && REG_CANNOT_CHANGE_MODE_P (REGNO (SUBREG_REG (in)), GET_MODE (SUBREG_REG (in)), inmode)) #endif ))

That || needs to be inside the #ifdef, so it can't follow on the same line as the "== NO_REGS))".

And once you're doing that, might as well use them for the whole file.

One plus of the former is that you can add a new clause without needing to edit an existing line, makes for cleaner diffs during reviews and makes it such that you wouldn't show up as the last person who touched the existing line in git blame or any other source control equivalent.

I prefer the operators at the start because the start is less jagged, so the operators don't get spread out so much and stand out more.

Usually I only put them at the end of a line in languages that do implicit line endings, and will false-positive when you move the operator to the next line (i.e. javascript and visual basic).

Javascripr lets you put the binary operators in the next line if you want. It won't insert a semicolon there:

http://blog.izs.me/post/2353458699/an-open-letter-to-javascr...

I would say that the most common problem is having a semicolon not being inserted if you start a line with `(` or `[`. In practice, the only time when a semicolon gets inserted where it shouldn't is when returning an object literal.

Jshint still complains about it even though it's technically okay.

It’s from the GNU Coding Standards, section 5.1 Formatting Your Source Code¹:

When you split an expression into multiple lines, split it before an operator, not after one. Here is the right way:

    if (foo_this_is_long && bar > win (x, y, z)
        && remaining_condition)

1) https://www.gnu.org/prep/standards/html_node/Formatting.html

Personally I find it easier to read the conditionals lined up in columns and with indentation on the left than at the end where they may or may not be lined up depending on the length of the expression.

I like the former, since it's more readable. I mean as in written English, you should put conjunctions at the start of a new line instead of letting them "hang". So you get

constant...

or get code...

or strict low

instead of

constant... or

get code... or

strict low

I like the operator at the beginning because you can see the type of comparison at a glance, but most everyone I've talked to prefers them at the end. To each his own, I guess.

for copy&pasting around this is very practical, also with arrays:

$moo =

[

    a

  , b

  , d

];

// insert c

</pre></code>

better than having the delimiter at the end, where you a) have to take care where you relocate the last element and b) could forget to remove it at the last element (most language parsers tolerate that though).

much better readability due to proper alignment...

Reply on news.ycombinator.com