views:

381

answers:

18

For example, what piece of code is considered better styled? If I show my code to a professional developer and ask if my code is good or not, will using the second style be probably considered as a (minor, but...) minus or a plus to my code quality?

I myself tend to like the second style but would prefer to comply to the most common opinion in this case.

1

val foo : Int = -1
val bar : Int = 1
val yohoho : Double = NaN

2

val foo    : Int    = -1
val bar    : Int    =  1
val yohoho : Double =  NaN
A: 

Whatever suits you, you're the coder. The second one just looks funny to me really.

Claudiu
+1  A: 

Whatever suits you, you're the coder. The first one just looks funny to me really.

Byron Whitlock
+4  A: 

It's just my humble opinion, but I personally just hate indentation like the second variant in any programming language. Some claim that "it looks nice" but I find it completely impractical. For example in order to rename the variable yohoho you have to realign all the other variables around (and most editors won't help you with that).

Adam Byrtek
+3  A: 

Python's PEP 8 (which is the "Style Guide for Python Code") requests that you don't use whitespace to align code:

Pet Peeves

Avoid extraneous whitespace in the following situations:

....

- More than one space around an assignment (or other) operator to
  align it with another.

  Yes:

      x = 1
      y = 2
      long_variable = 3

  No:

      x             = 1
      y             = 2
      long_variable = 3
dln385
Which would be a great answer, if the question had been tagged *Python*
Kevin Wright
Well, the Puppet Style Guide says you should vertically align declarations. And what's either of them to do with Scala style?
Daniel
A: 

Whatever suits you, you're the coder. I find the second one is more of a pain to edit.

Sam Dufel
+1  A: 

Whatever suits you is only good enough if you work on your own. If you're part of a group of developers, you should vote and stick to one way. Keep a list of coding standards and enforce it in code reviews.

Juan Mendes
+3  A: 

I've tried this with Python, for instance in Django model declarations.

It becomes an OCD inducing pain when you're modifying the code later on. For instance, what if you add a var called yoohoohoey in the 2nd example? You have to go back and add spaces to each line to align it to the new length.

So, I prefer to do things the first way.

Alex JL
What is an OCD?
Ivan
@Ivan obsessive compulsive disorder - http://www.nimh.nih.gov/health/topics/obsessive-compulsive-disorder-ocd/index.shtml (meaning you feel like you have to get the code looking just right). Might be a bit of an exaggeration in this case.
Alex JL
@Ivan [Obsessive–compulsive disorder](http://en.wikipedia.org/wiki/Obsessive%E2%80%93compulsive_disorder) - he's saying that lining up your code forces you to realign it every time you make a change. Wasting time on lining things up is typical of OCD.
dln385
Oh, I already have it. That's why I rewrite my project from scratch every week, and that's why I came to this question. I just hope to write an absolutely perfect (including style) class once, then I'd have no motivation to rewrite it again.
Ivan
A: 

I can't speak for Python, but in general you will find both examples across all different languages. In my experience, the first example is more common, but it's a matter of personal taste and I don't believe that another developer would think poorly of you for using either style.

I greatly prefer the first example and agree with others who have commented on the maintainability of the second example. With syntax highlighting available in all IDEs and most quality text editors these days, I don't think the latter style is necessary to keep things readable.

Steven Benitez
+9  A: 

Did you change your tags? I see several answers referring to Python but the only language tag I see is Scala. If you're interested in Scala I would refer to the unofficial Scala Style Guide. Based on the style guide I would suggest your example should look like this:

val foo = -1
val bar = 1
val yohoho = Double.NaN
pr1001
+1  A: 

I use the second way, if necessary. Is time consuming to do, but with a bit of time you can configure the auto formatting to make it automatically.

But this is a matter of preference.

adelarsq
+2  A: 

Scala doesn't force you to work in either style, but the first is generally preferred because it can really play havoc with diff tools if you have to add a new line and then respace everything else...

On the other hand, if your code/algorithm is much more readable when it's aligned, then align it! Readability trumps all other concerns, as per the agile manifesto:

  • Individuals and interactions over processes and tools

i.e. It's more important to keep other programmers happy than to keep diff tools happy.

Kevin Wright
+2  A: 

The second style will get messed up when variables are renamed using refactoring tools.

starblue
+1: Only answer mentioning refactoring.
Andy Thomas-Cramer
+1  A: 

The Scala Style Guide is silent on the subject, but I haven't seen vertically align declarations in Scala code, so I'd go with the first choice.

Daniel
A: 

From a usability standpoint while reading, the second is akin to a table layout and it helps you scan it vertically to quickly see that there're two Ints and one Double, but it's also slightly harder to connect the horizontal extremes to see that bar is 1.

The first one makes the individual rows take focus and is easier to scan horizontally to see that bar is 1 but it's harder to quickly see that there're two Ints and one Double.

Expand the example with a lot more lines and it might be easier to "feel" this - but which one to use would be up to which is more important and of course what style is used in the project, team, workplace or best practice for the language in question.

Also, why limit table layouts to only left-aligned columns? ^^

   val foo : Int    = -1
   val bar : Int    =  1
val yohoho : Double =  NaN
Oskar Duveborn
+1  A: 

How often do you have multiple initialized val or var declarations in a Scala file anyway? Top level vals and vars in classes should mostly be primary constructor parameters, if possible. Top level vals in traits will likely be abstract, and thus not initialized. Vals and vars inside methods should absolutely not be padded, as reordering is entirely too likely.

I just searched through a 200 class Scala project, and only found one class where this issue even arises (a "cake pattern" module, where the vals declare the components of my application). It's a non-issue.

Dave Griffith
A: 

If your goal is to conform to community guidelines, probably the first is more common. But are you looking to fit in -- or to stand out by the quality of your code? Learning what works for you is extremely important.

I suggest you try both styles -- then see how you find working with both. For me, aligning variables is a pain, but it's very helpful when working with larger code files. It's also a nice bit of busy work when I'm stuck on some particular aspect of code and want a little time to let my ideas percolate.

Along this same line of thought, I find that when working with, say, JavaScript, pushing the first line of a function to the far left allows me to scan code very rapidly. That breaks normal indentation rules -- but it's helped me read code far better than nicely indented code.

Hal Helms
A: 

Second style giving headache when you need to search for specific text. When code file grows large sometime you need to seek for specific text, If you coding with custom spaces it is hard to find.
We had bad experience with large XML files holding TSQL scripts, Coders before me using style 2 as in your example, end whenever We added new rule or upgrade old one it is painful to search trough files which is codded with custom spaces.

adopilot
A: 

This kind of indentation is useful when someone reads the code, but it is quite up to you to decide. My answer is don't use it, you will save some time, and you really want to use it, make some text editor that does it, or maybe do yourself some compiler that interpret printed html code, because it's worthless to do it on a text file, which I'll remind you, is a plain long line of bytes reorganized with tabs, space and return carriages.

gokoon