Laying out code opinions?

[Eamonn]

This is something that I've been thinking about recently because I know a lot of people(including myself) like code indented. Coming from Python you kind of get into the habit of doing it. But I saw my friends code the other day and he doesn't indent his code because he thinks it's 'ugly'. So, what are your opinions on it? How do you lay out variable declarations? Would you do:

Code: Select all

one = "hi hi hi"
twolol = 10

or

Code: Select all

one    = "hi hi hi"
twolol = 10

Would you indent your code? Would you comment your code? Would you over comment(like me) and leave a comment on every line like this:

Code: Select all

function foo() -- My function
    
end -- The end of my function

or would you leave out the comment for the end? I would put it in because it'll help with indenting and debugging as you'll know what end end's what function, if that makes sense.

I'm not saying your way is wrong/right, I'm just curious about how you layout your code.

Yes, this question is random, but I've seen some really random threads in the general section not related to code, whereas this is related

I just want to know what way other people lay out their code, after seeing that guy the other day not indenting or commenting.

My Style:

Code: Select all

foo = "iifsdiofsofs"
bar = 10

function hi(name) -- My function that takes a name argument
    print("Hello World, " .. name) -- Prints hello world with whatever was entered for the name parameter
end -- Ends the 'hi' function

table1 = {
    x = 10,
    y = 10,
}


-- 2 extra lines at the bottom for no reason :P

Feel free to add anything else that you add that I haven't mentioned!

[Kingdaro]

Your style is very typical of most programmers, and your friend is going to have trouble reading his code without indentation.

[micha]

I don't see a big point in aligning equality signs.

If I have many nested do/end constructions, like you, I often put a comment to the "end" to clarify what ends there, especially when beginning and end are far apart.

I recently stumbled upon the coding style guide written by Linus Torvald: Link
There are some ideas inside. I like these two:
1) If you have more then 4 indentation levels, then you should split up the code and use functions
2) Write comments, what is done, not how it is done.

[raidho36]

Write comments, what is done, not how it is done.

You should do both, especially if code is complicated and you have things like refereces to references and other such obscure stuff.

I don't see a big point in aligning equality signs.

It's prettier that way, and may be easier to edit your values since you wouldn't have to scroll. I ident a lot of stuff that way.

If I have many nested do/end constructions, like you, I often put a comment to the "end" to clarify what ends there, especially when beginning and end are far apart.

My editor just highlights me my blocks.

[Plu]

I also prefer to let the editor handle the block highlighting. Indenting variables looks a bit cleaner, but isn't really neccesary.

And indenting blocks is absolutely vital. Not doing that means you will never be able to easily figure out what your code is doing anymore.

As for 4 blocks means making functions... I'd say 3, tops. Preferably 2. More functions is pretty much always better when it comes to readability and reusability.

[raidho36]

But you shouldn't put readability above performance nevertheless, and having a function for every single fart would definitely tamper it. Having code easy to read does not equal having it easy to maintain, let alone reuse. Easily reusable code is the one wrapped to a library (the most basic way you reuse a code), and what' it looks like under the hood is of noone's concern.

[Eamonn]

Please don't turn this into an argument Bartbes is probably already annoyed at locking one of my threads!

[Inny]

In my experience, this style of coding, across many languages, tends to lead to the least arguments. Python's PEP8 kind of makes these establishments.

• short but descriptive variable and function names
• comments explain why the code exists and why it does what it does, rather than what it does (because the code itself explains what it does)
• don't use comments to indicate where a function ends, the end keyword and indentation does that for you
• start a block on the same line as the thing that uses it, so if ... then\n rather than if ...\nthen (\n is the newline)
• indent to what everyone else indents at (for instance, 2 for lua, 4 for python)
• don't add indentation in the middle of a statement (meaning aligning to the equal sign might get frowned on)
• However, do make sure you use spaces where appropriate, like after commas and around operators like + and - and == and so on
• 78ish is where your line is getting a bit long and maybe it's time to put a new line in there
• if a statement spans multiple lines, give an extra indent to the subsequent lines so thats clear
• people kind of expect Classes to be Capitalized and methods and variables to be camelCase or lowercase_with_underscores
• leading underscores for _variableNames are how you say "internal detail, please don't mess with this"

These are, again, mostly adopted for the least amount of argument around them, and you see a lot of this kind of stuff in other languages as well. There's more on this wiki page: http://lua-users.org/wiki/LuaStyleGuide, and Python's PEP8 is always a good read to see how the other half does things, http://www.python.org/dev/peps/pep-0008/

Because there's lots of work to be done actually writing code, fighting about the code style is ultimately unproductive, so don't spend too much time on it and you'll do fine.

[Eamonn]

In my experience, this style of coding, across many languages, tends to lead to the least arguments. Python's PEP8 kind of makes these establishments.

• short but descriptive variable and function names
• comments explain why the code exists and why it does what it does, rather than what it does (because the code itself explains what it does)
• don't use comments to indicate where a function ends, the end keyword and indentation does that for you
• start a block on the same line as the thing that uses it, so if ... then\n rather than if ...\nthen (\n is the newline)
• indent to what everyone else indents at (for instance, 2 for lua, 4 for python)
• don't add indentation in the middle of a statement (meaning aligning to the equal sign might get frowned on)
• However, do make sure you use spaces where appropriate, like after commas and around operators like + and - and == and so on
• 78ish is where your line is getting a bit long and maybe it's time to put a new line in there
• if a statement spans multiple lines, give an extra indent to the subsequent lines so thats clear
• people kind of expect Classes to be Capitalized and methods and variables to be camelCase or lowercase_with_underscores
• leading underscores for _variableNames are how you say "internal detail, please don't mess with this"

These are, again, mostly adopted for the least amount of argument around them, and you see a lot of this kind of stuff in other languages as well. There's more on this wiki page: http://lua-users.org/wiki/LuaStyleGuide, and Python's PEP8 is always a good read to see how the other half does things, http://www.python.org/dev/peps/pep-0008/

Because there's lots of work to be done actually writing code, fighting about the code style is ultimately unproductive, so don't spend too much time on it and you'll do fine.

I agree, it'll be like the eternal war over coding on a dark background VS a light one. I won't even make a thread about that because people would argue about it for ages and it'd probably end up getting locked Though I tend to use a darker background. I like blue(as you could probably tell by my avatar), so I like to use blue themed themes. Though Cobalt is nice, it kind of started to annoy me for no reason. So now I use "Solarized(Dark)" in Sublime Text 2.

Anyway, I'll check out the Lua Style Guide. I didn't make this thread for people to tell each other whether their style was wrong or not, I made it so I could see how the majority type their code.

In Java/any language that uses curly braces I switch between these layouts(depending on my mood)

Normally, its:

Code: Select all

int lol() {
    code
}

Sometimes:

Code: Select all

int lol(){
    code
}

2nd most used:

Code: Select all

int lol()
{
    code
}

[riidom]

I use indentation of 2, so I can nest a lot. I wouldnt think about getting stuff in a function (that is likely to be used only once then) due to too much nesting, because I would have to hop too much around then while following the codeflow.
The problem with a long tail of end's I solve with blank lines, that separate several steps inside a function from each other. Also, I make a blank after function f(x) and before the end that is related to the function line. Unless the function is short, then I tend to compress it as much as possible.
Between 2 functions come 2 blank lines, and I do a new text file for each class. I might re-think the last statement, once I get way more classes, but for now it works.
Comments I use mainly for hardcoded variables, so I can find them easier if I go tweak something, or to explain myself the structure of complicated tables.
If I compressed my code so hard that I know I wont understand what it does and why, a week later, I rather write it more noobish and better readable instead of adding a comment that explains me what I created there in some random brilliant moment. That is just my personal opinion, but I dont see much sense in obfuscating/optimizing expressions just that I can save 4 chars to type and get a headache in a future point trying to read it.