[discussion] Code style

[abenkovskii]

We need a of code style for this repo.
Here is an example of what happens if we don't have it: akrasuski1@75da267
In my editor there were spaces and than they turned into tabs making it hard to see where the real difference is.

[Dunbaratu]

I think it may discourage contributions from newbie programmers to complain about things like not using the same type of declare parameter.

Tabs and spaces on the other hand are a big deal because they make fake diffs. Tabs really only work if you rigidly adopt the rule that all indents must consist of only tabs and never use any mix of tabs and spaces. If you do that, then individual viewers can set their tabstops where they like and effectively change the visual presentation of the whole file. But the instant there is a mix, it doesn't work because people viewing in different settings see different things and the lines don't match if a mix of people have edited it. Also, only in some contexts can you set the tab size. So sometimes hard tabs are going to appear way too wide in their standard size of 8 and you can't do anything about it (like in github diffs).

I favor a spaces-only rule to a tabs-only rule. But both are preferable to a mix of tabs and spaces.

But I see the appeal of tabs in kerboscript where people are trying to reduce char count. But I'm against that ridiculously tight limitation, and always have been. It encourages people to write horrible looking code with abbreviated gibberish variable names. People claiming "but they only had a few Kb on Apollo" keep forgetting that they weren't sending the source code, and they weren't using an object-oriented hardware abstraction. The comparison doesn't work.

[abenkovskii]

@Dunbaratu It's good that they didn't realize that making the whole program one long line considerably reduces the size of complied file.

[abenkovskii]

@Dunbaratu I vote for spaces for 2 reasons:

1. my editor uses spaces
2. there are no tabs in the built-in kOS editor

[TDW89]

I use spaces so that would be my preference to. Also I really like the format:

parameter 
 arg1, //description of arg1
 arg2, //description of arg2
 arg3. //description of arg3

especially as an aid when other people are going to be using your lib files and don’t necessarily want to (or can't) go look at documentation for it because they forgot which way round the args were supposed to be.

[abenkovskii]

@TDW89 What do you think about

function foo {
  if condition {
  } else {
  }
}

vc

function foo
{
  if condition
  {
  }
  else
  {
  }
}

I personally prefer 2nd variant.
P.S. I'm not 100% sure we should go for such a detailed code style. There are many kOS users that are not familiar with programming.

[TDW89]

um not sure on that i have been using

function foo {
 if condition {
  stuff.
 }
 else {
 }.
}.

so similar to the top one but on continuing on a line after i have just closed a brace.

[abenkovskii]

@TDW89 Yes there are a lot of possible variations. I think I'm using the simplest rule possible: each brace on a separate line.
P.S. Never knew that you can put . before else.

[TDW89]

@abenkovskii you cant (updated example)

[abenkovskii]

@TDW89 actually you can

[TDW89]

ohhhh that’s new.

docs probably need changing then

[abenkovskii]

No. Let's not document it. It looks bad.

[TDW89]

the docs currently have a statement saying that it will produce an error. I was thinking that that just needed removing as its not true any more. Not adding anything that explicitly states that it is now possible.

[Dunbaratu]

I always hate the extra blank vertical space that this standard causes:

    if blah
    {
        blah.
        blah.
    }
    else
    {
        blah.
        blah.
    }

It's a ratio of only half the lines being the code and the other half being formatting.
That's a massive waste of precious vertical screen space, especially when you have people who think that a function's body must fit in one screenfull - I keep wanting to fire back, "but the actual code DOES fit. It's the idiotic wasteful formatting you forced on me that doesn't fit."

It gets worse if you decide to follow the (good) practice of using braces even when it's optional because the body is only one statement. Then the ratio of code to formatting gets even worse.

I rankle at the fact that erendrake chose that formatting for the mod.

And you don't have to go with type 1 as the alternative. If you like the braces to line up AND to not waste the lines, you have this:

    if blah
    {   blah.
        blah.
    } else
    {   blah.
        blah.
    }

You get both in one standard that way. But sadly, most people think it's impossible because their editors don't understand that it's an option and fancy IDE's keep trying to 'fix' it on them.

[abenkovskii]

That's one of the reasons why I like python: no braces - no problem

[abenkovskii]

It's actually a case of habit: for me your last variant looks awful and I'd prefer leaving braces at the end of the line if screen space is a problem.