Code Styling. What do you prefer?

General Discussion Off Topic
41

I still wanna hear that story :wink:.

2 Likes
42

Nowadays I always use the right style, even in C.

43

I used to use K&R style (lefthand side) exclusively, but the over years I started keeping my braces on the same line. It looks cleaner to me.

44

This probably deserves an unpopular opinion puffin but… whatever: I don’t evangelise or loathe either one any more and the reason is something that I actually feel can be learned, because I learned it.

See I didn’t start off neutral, I literally used to absolutely loathe, hate and utterly despise the egyptian brackets, they felt all wrong because my starting languages were Turbo Pascal and C++. In Pascal, block statements have a BEGIN and an END statement which gives you a pleasing visual symmetry with blocks, which conceptually looks like this:

It feels like the block statements “contain” the code block and it’s very easy and fast to follow visually. The C style I was introduced to (which turns out to be “Allman Style” according to Wikipaedia) preserves this visual connection very clearly:

For an extremely long time (I started programming in 1989, and only changed my mind last year) I couldn’t fathom how anyone could look at the Java convention and not just feel visually jarred by it. When looking at Java code this is how I saw it:

The nice symmetry felt utterly broken, and the visual disconnect between the braces was the hardest part to understand because that visual cue which I subconsciously (and that’s the key word, and is why looking at alien code “feels” so uncomfortable) searched for was not present. Worse, when you do manage to spot the braces they felt “lop sided” and just added to the overall feeling of discomfort.

But what @Psifour said above is absolutely right, you stick to the standards of the project you’re coding for, regardless of your personal preferences. When I started work on Sponge I knew the Java code style was going to make me uncomfortable, but I didn’t consider for one second that I wouldn’t stick to it.

This led to something for me though, after years and years of not being able to consider the Java style anything but ugly, the logic of it slowly started to coalesce for me, and without me really even noticing it, suddenly it looked tidy to my eyes. I was quite literally blown away by the revelation.

“Oh no!” I thought. “What if I now look at my (thousands upon thousands) of lines of existing code and they look ugly to me?!”

But they didn’t. I went and browsed through my existing codebases and felt pleased at the neatness, then looked back at the Sponge code I’d written and felt equally happy. This is somehing I’d been conditioned to believe wasn’t possible. Aren’t we supposed to evangelise our code style? Isn’t it supposed to be one of the quintessential divisive issues of the programming caste? How can it be possible to like both styles?

I thought about it for a while and realised why. Somehow it had sunk in that when looking at code with egyptian brackets you do not visually cue from the braces themselves; that it is instead the flow and shape of the code itself that you begin to visually follow. I looked at the code like this:

The braces are still a component of the visual acquisition of the code block, but they play a secondary role to the shape of the code itself. This might not be how it works for everyone but it’s certainly how it began to work for me.

What I’d learned (and what I realise now, anyone can learn) is that by forcing myself to use a style I hated, my brain had simply learned the new visual cues required to comfortably scan the code.

When we realise that it’s not the aesthetic properties of the code style, but the purely functional aspect of our brain scanning and parsing code we’re looking at, it suddenly becomes obvious why this is such a divisive issue. We look at code in an unfamiliar style and it doesn’t look like code to us, we label this feeling as “ugly” in our mind because that’s what it feels like, but we’re wrong. Code in an unfamiliar style isn’t intrinsically more ugly or more beautiful than any other, it’s simply that alien feeling which makes it seem so.

I do still believe that good code has an aesthetic component, this is true on a lot of levels and it’s why auto-formatters suck so much; every rule has its exception and code style is about clarity, not rules at the end of the day.

So do yourself a favour. It took me more than 20 years to get here, but that fact alone means it’s possible for anyone. Stop evangelising your code style and learn to embrace the diversity of the brace. It makes life a lot more pleasant believe me.

All code can be beautiful.

…

Well… okay, except Perl.

25 Likes
45

… You are correct, but did you really have to make all the other posts look bad by making art for yours? I feel like all my posts are sub-standard now :smiley:

Hopefully, I eventually reach the point that I find other styles to be as visually appealing as Egyptian, but that would require me to not be a Java fan boy.

46

Ew. Don’t be a Java fanboy, it’s only a language, not a religion (huh? who said that?)… xD

47

Religion you say? Do you wish to hear about our lord and savior java 8? :trollface:

5 Likes
48

This is all very well stated. That helps put some things into perspective for me.

49

I don’t follow specific conventions when I program. I don’t know what you think of my conventions, but I like it. Constructive criticism is welcome.

If/else:

if(stuff="stuff!") {
    //Whatever... |:-]
} else {

}

Try/Catch:

int answer;
try {
    answer = 5/0;
} catch( ArithmeticException ignorable){
   ignorable.printStackTrace();
}

Empty Bodies:

public class TotallyUseless {}

Imports: (ex)

import org.spongepowered.someclass;
import org.spongepowered.otherclass;

import com.google.bitbite.exe; //Easter Egg!
import com.google.kill.mafia;

import java.io.IOException;
import java.lang.*; //Useless, but do I care?

import static java.lang.Math.*;
import static com.mojang.notch.Notch.getNotch; //note how I grouped all static imports together!

Really Long Code: (formatting messed up)

UselessyLong = LongCode.getCode().getLength().getUselessProperty().append(LongCode.getHairColor().getRGBColorCode()
    .toString().toUpperCase());
50

@Mumfrey, I was discussing the brace style with some professional programmers and they pulled up a strong reason against that brace style.

If I have code

if (X)
{
  dangerousReset();
  many lines of reboot code
}

and a new member has to work with the code, they can now do

if (X)
preresetOp();
{
  dangerousReset();
  many lines of reboot code
}

which always runs, this may not be valid java, I don’t know if java supports the scope operator. But in C++ and C this is a critical flaw. Regardless of the fact that they shouldn’t use a single line if statement, it provides a huge error window, a mistake waiting to happen.

Do you have a counter, other than make sure that doesn’t happen?

51

Whilst defensive coding is all well and good, relying on code style to prevent people doing stupid things doesn’t seem like a strong enough argument for one way over the other, and as I said, the key is to stop evangelising code style. I personally see the merits of both.

The scenario you’ve mentioned is akin to this:

if (X) preresetOp(); {
    dangerousReset();
    many lines of reboot code
}

and if that looks ridiculous to you then that should give you an idea of how strange your example looks to me. As I mentioned above, the whole attraction of the allman style is that the braces form an integral part of the whole statement visually (whereas in java style that’s not the case) and you simply would not put a statement between a block statment and its opening brace.

The point is valid for open source projects where many people may be working on a project and some of them may not grasp the code style and mistakes can be made, at which point the defensive style makes more sense because you want as many barriers in the way of people making mistakes as possible. But for anyone used to working in that style it just simply wouldn’t happen. As I said I’ve been using the same style for almost 25 years and have simply never encountered what you’re describing, although I acknowledge that it can.

I think you missed the point of my post anyway. 99% of the arguments over style seem to focus on the aesthetics, and my entire point was that from a functional perspective of being able to efficiently read and understand code they both have their merits and can work equally well, and that evangelising styles doesn’t really help anyone at the end of the day.

What really gets my goat though is that you can preach tolerance and understanding as much as you like, and there will still be someone who goes, “well yes, that’s all very well, but my opinion is still better”. I think you missed the point.

1 Like
52

No I just wanted to know what your solution was, because I do prefer the seperate line style myself. But in discussion it seemed that there was a functional argument which might be interesting to discuss.

53

Your spacing is somewhat inconsistent. Remember: spaces after keywords, and no spaces after opening parentheses.

1 Like