Jump to content
Sign in to follow this  
CarlGustaffa

Strict or loose programming style, opinions

Which coding style do you prefer?  

34 members have voted

  1. 1. Which coding style do you prefer?

    • Strict class styling.
      14
    • Condensed styling, but strict.
      2
    • Condensed styling, also allowing one liners where simplicity allows it.
      14
    • No rule, mix and mingle everything, including complex one liners.
      4


Recommended Posts

Hi

I would like some input on what kind of coding style people prefer to do themselves and why one or the other is more easy to read.

Take the following examples:

// class style
if (_test) then
{
//do something
}
else
{
//do something else
};

//condensed style
if (_test) then {
//do something
} else {
//do something else
};

//one liners
if (_test) then {/*do something*/} else {/*do something else*/};

I see a lot of code snippets nowadays where people use "class style" very strict styling. In my personal view, I find this to create too "long" scripts when it isn't needed. The examples go from 8 lines, via 5 lines, to 1 line.

Is there a benefit to using "class style" that I'm just not seeing? I tend to be a bit loose, where I normally do "condensed style" where opening bracket is included on the keyword line, but even allow "one liner style" if the code is really simple and not nested. In my script editing software (UltraEdit), collapsing code does it at the bracket, which means I don't get that extra line visible which contain the keyword, then the bracket. Means that "condensed style" also when collapsed tend to be more, well, condensed :p Which to me improves working with it.

So, finally, the actual question:

Which style do you prefer?

1) Strict class styling.

2) Condensed styling, but strict.

3) Condensed styling, also allowing one liners where simplicity allows it.

4) No rule, mix and mingle everything, including complex one liners.

and also share why.

Edited by CarlGustaffa
whups :p

Share this post


Link to post
Share on other sites

Number 3# with the one liner when doing a simple assignment.

Never use code folding (collapsing). I prefer that every line (except empty) lines does something useful if I have to type it myself. A single { and } doesn't tell me much. However, if the convention and tools encourage something else I do that. Eg. in VS C# I use (well the editor really) #1 (I think).

Share this post


Link to post
Share on other sites

Condensed (#3) all the way for me. I also find it the easiest on the eye.

Offtopic:

I have noticed that since I started using Mikero's PBO tools all the configs seem to be in the strict style, regardless if I wrote them in condensed then unpacked them...weird.

Edited by Hellfire257

Share this post


Link to post
Share on other sites

shit, voted for one but actually I do a mix of 1 and 2. I usually put the first { after the "then" on a new line. This way it is much simpler to spot chunks of code and where scope begins and ends. Leaving the leading { at the end of a line forces your eye to jump around from left to right looking for it, but "} else {" I just look at as one single statement thus no need to break it into 3 lines.

But I have to admit that this probably varies between languages and their IDE's. For C++ and C# I use VS2010 with VAX which already places prefabs like if blocks with 3 button presses. For SQF and other I use NP++ which probably makes me work a little shorthand.

Share this post


Link to post
Share on other sites

#1 strict style for me. I find it syncs with how my brain works. Here are some of my personal reasons why:

1. Ease of commenting - Most of my projects tend to involve complex scripted systems so in order for me to remember which code does what, I comment almost every line so I can remember what I am doing and help me debug. I realize I can comment inline with /* ... */ but I can read it easier if on separate lines. This also applies when posting example code in the forums and trying to explain what something does.

2. Fewer syntax errors: I make far fewer syntax errors in strict style. Yes, I use squint to check my code but I have found i hardly need to using a stricter style. If i have a { at the beginning of a code structure and everything indented between I know when my }; is there more easily. I also do this for complex nested arrays. Hell, you should see one of my particle param arrays, I put almost every parameter on a seperate line (except RGBA, positions, etc).

Again, all this my personal preference.

Share this post


Link to post
Share on other sites
Again, all this my personal preference.

That's what it really boils down to!

EDIT: I should add.... condensed with one liners for me! ... so number 3.

Edited by twirly
Added stuff

Share this post


Link to post
Share on other sites

I accidently voted #2 , but I meant to vote #3.

I think it really is personal preference.

Share this post


Link to post
Share on other sites

i dont have style it just has to be clear. and not bloat script file just because i would want to use the "class style"

so i can write in class style mostly, or one line:

if(alive unit) then { hint "hello"; } else { exit; }

// more code 

or

if(alive unit) 
then { hint "hello"; } 
else { exit; }

// more code 

to keep it short and clean.

Edited by rrr44

Share this post


Link to post
Share on other sites

It is personal preference, but

  • IDE have auto display conversion
  • readability is one of the key aspects of code quality
  • the three certainly differ in readability

My take is that #1 is the best. Very clean and clear structure.

#3 is bad - at least if it goes complex, aka more than if (a) then {b=true;};

You show this nicely with your example as you forgot the opening bracket for the else tree. :)

Nowadays with large monitors and high resolutions there is hardly any bloat possible.

If there is, it is not due to the display style but due to bad code design.

Share this post


Link to post
Share on other sites

While not perhaps not exactly on topic I just though I'd post this from PEP 8.

Consistency with this style guide is important. Consistency within a project is more important. Consistency within one module or function is most important.

Replace "this style guide" with "the style guide" and I think that a pretty good rule of thumb.

On topic:

I actually find it more important that correct indentation is used that where the braces are. Usually I don't "actively" see the braces of conditional structures; I notice if they are there or not though. What matters for readability to me primarily the indentation.

Edited by Muzzleflash

Share this post


Link to post
Share on other sites

Correct. However you enforce a server side style.

The IDE does the conversion automatically to server and the client can have his

custom style on the local machine - also provided automatically by the IDE.

Thankfully there are now IDEs available also for arma/SQF.

Share this post


Link to post
Share on other sites
...

You show this nicely with your example as you forgot the opening bracket for the else tree. :)

Whups, fixed :)

Share this post


Link to post
Share on other sites

Condensed with one-liners because it's the easiest to read and write. Bringing anal professional programming rules into Arma 2 scripting is just useless most of the time. Chances are you're not writing a mega script that has several authors who simultaneously work on it.

Edited by Celery

Share this post


Link to post
Share on other sites

For me it depends. If I can condense it to one line I will, but if there are multiple things going on then I prefer strict class styling so that I can easily see where blocks of code start and end. I think it partly depends on how your brain organizes things, so there is certainly no right or wrong way. I just try to be consistent :)

Share this post


Link to post
Share on other sites

switch (_task) do {
   case "taskAttack" : {
       [_group, _destination, _radius] call CBA_fnc_taskAttack;
       if (debug) then {
           player sideChat format ["%1: Faction is %2, location is %3, radius is %4, destination is %5",_task,_faction, _location,  _radius, _destination];
       };
   };
   case "taskPatrol" : {
       [_group, _location, _radius] call CBA_fnc_taskPatrol;
       if (debug) then {
           player sideChat format ["%1: Faction is %2, location is %3, radius is %4",_task,_faction, _location, _radius];
       };
   };
};

An example of my preferred style.

Share this post


Link to post
Share on other sites
If I can condense it to one line I will...

Did you work on ECS for Arma1? :D That is one (and I mean one literally) serious one liner that took some effort into making readable :p

So far it's pretty tied, which I have to say surprises me. Wasn't expecting that much votes for #1 (strict style), even if that is what I have noticed lately in posted examples and so on.

I use #3 myself (condensed with one liners if appropriate), and was wondering if I should adapt strict, just to follow the flow. But looking at the link Muzzleflash provided for "serious programming", I see they're more concerned with efficiency and readability than being utterly strict about it, so I'll just keep on doing what I'm doing.

But what about when using snippets made by others? I.e. when using BIS functions rewrote to suit own needs (which tend to be strict styled), or other peoples scripts which may have quite horrible style to it - is it considered okay to change it? Keep in mind the rule "try to remain consistent".

Personally that is the rule I live by, try. If I paste stuff into existing scripts, I change without thought of "stepping on toes" to remain consistent. But also, if I use a whole suite of scripts (typically in own directory) to do a certain task, I may choose not to update it so that changes can be more easily spotted using compare software when a new version arrives. Any thoughts?

Oh, and yes, "proper" indentation is also part of this conversion process.

Edited by CarlGustaffa

Share this post


Link to post
Share on other sites

i like a mix of #1 and #2

if (foobar) then
{
   //code;
}else{
   //code
};

switch(true) do
{
   case foo:
   {
       //code;
   };

   case bar :
   {
       //code;
   };
};

Edited by nuxil

Share this post


Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
Sign in to follow this  

×