17 replies to this topic

[guest3456]

i used to do the if with the { on the same line, but now i put it on its own line for better readability

same with the parens, i now use spaces too to pad the parens so the inside is easier to read

ive done both, my preferences keep changing. but because of that, sometimes my code isn't consistent and there are both types

[MasterFocus]

i used to do the if with the { on the same line, but now i put it on its own line for better readability

My case was the opposite. I started favoring readability and eventualy, when I got really confident with the syntax, changed to if ... {.

Also, Guest asked about spaces between parentheses...
Well, I don't see any difference, but the thing is: I always use an expression. Never something like if var = text (althought sometimes I may use if var in x,y,z, but still rarely)
Even 95% of my assignments use := instead of = (unless it's a really special case or something).

[SKAN]

I prefer to avoid curly braces, whenever I can:

Loop %A_WinDir%\*.*
 If ( A_LoopFileTimeModified >= Time )
    Time := A_LoopFileTimeModified, File := A_LoopFileLongPath

MsgBox, Lastest file in %A_WinDir% is `n`n%File%

:= is for assignment, = is for comparsion. That is the best way for everybody, unless people require autotrim.

[G. Sperotto]

I usually use indentations and braces like this:

If ()
{
     This will be done.
     if ()
     {
          This will be done.
     }
}

I also try to dismember the code into small functions (15 lines max) and create an index for all these functions. The function names should resemble what they do and any variable names should resemble the meaning of the values they hold.

[Wingfat]

I prefer to avoid curly braces, whenever I can:

Loop %A_WinDir%\*.*
 If ( A_LoopFileTimeModified >= Time )
    Time := A_LoopFileTimeModified, File := A_LoopFileLongPath

MsgBox, Lastest file in %A_WinDir% is `n`n%File%

:= is for assignment, = is for comparsion. That is the best way for everybody, unless people require autotrim.

I really need to read up more on this part... I'm always using "Curly Braces" ;-)

[guest3456]

I really need to read up more on this part... I'm always using "Curly Braces" ;-)

nothing to read up on

SKAN will still have to use curly braces in cases where he needs a block of code more than one line, unless he wants to chain them all with commas

no curly braces means only the very next line will be executed if the condition is true

[rbrtryn]

Time := A_LoopFileTimeModified, File := A_LoopFileLongPath

Personally, I can't stand when two statements are on the same line. I think it's confusing and and it makes the script harder to debug. I much perfer logically grouping the statements with braces.

:= is for assignment, = is for comparsion. That is the best way for everybody, unless people require autotrim.

+10

I only use expression ifs and expression assignments. I use one true brace formatting whenever possible:

if () {
}

[hoppfrosch]

:= is for assignment, = is for comparsion. That is the best way for everybody, unless people require autotrim.

+10 as well

I also prefer OTB (One true brace) style

if () {
}

This has also advantages in code folding editors: it folds up to one single line

if () {

instead of

if () 
{

In opposite to SKAN I also tend to use ALWAYS the braces - even if only one codeline is part of the if-block. This makes it easier for me to read code fluently, as there is always a visual mark to identify end of block (+ code folding is possible - and the "code folding lines" (don't know the correct term) of the editor shows the end of the block ...).

I also try to avoid two or more assignments on one line.

Generally I don't like the sophisticated oneliners (compacted code) as often seen in perl for example - they almost only demonstrate the coolness of the programmer, making it very hard to understand for others. I prefer readability over compactness.

[maul.esel]

I used to use OTB and as less braces as possible, now I tend not to use TB but more braces - possibly I'm influenced by C# (or more specifically, the C# Express IDE which does it that way).

About combining lines: I see it is harder to read, nevertheless in AHK it is even faster. You can always do sth like this:

if (true)
    A()
    , b := true
    , c()

With this you can omit braces if you like to, you have the extra speed but ti's still readable. All advantages combined

[maul.esel]

AHK concats lines starting with an operator, such as comma. So internally AHK sees this:

if (true)

    A()

    , b := true

    , c()

as equal to this:

if (true)

    A(), b := true, c()

Which is just one line and therefor the if needs no braces.

[rbrtryn]

About combining lines: I see it is harder to read, nevertheless in AHK it is even faster. You can always do sth like this:

if (true)
    A()
    , b := true
    , c()

With this you can omit braces if you like to, you have the extra speed but ti's still readable. All advantages combined

No offence intended, but that style is going to introduce bugs which are nightmarishly difficult to find, i.e.

if (true)
     A()
     b := true
    , c()

IMO, losing the logical grouping afforded by the braces just to gain a few milliseconds just isn't worth it.

[maul.esel]

Well, I didn't have the problem yet. But braces can be combined with line concatenation if you occur to have problems with missing commas.

[rbrtryn]

I prefer readability over compactness.

+1 That is my philosophy as well. The goal is readable, self documenting code.

Also check out this other thread: Coding Style Guidelines.