19 replies to this topic

[rbrtryn]

Some useful advice from the inventer of Linux, Linus Torvalds.

Linux kernel coding style

[G. Sperotto]

I keep seeing people ignore the absolut need of planning the overall organization/maintainability in a script. It's just a matter of time till they find themselves with a 500 lined headache-o-matic of a code.

But the most funny thing is watching them post "whats wrong with my code!!?!?!?!??" in the support session :lol:

[jballi]

I had trouble getting past the first chapter.

[quote name="Chapter 1]Now, some people will claim that having 8-character indentations makes the code move too far to the right, and makes it hard to read on a 80-character terminal screen. The answer to that is that if you need more than 3 levels of indentation, you're screwed anyway, and should fix your program.[/quote]
I like reading an instruction guide that tells you what to do and then insults you (and your code) if you don't like it. :wink:

[guest3456]

valid warning though

In short, 8-char indents make things easier to read, and have the added
benefit of warning you when you're nesting your functions too deep.
Heed that warning.

[fragman]

I tend to disagree, atleast for an example like this:

class test

{

	f()

	{

		loop 10

		{

			if(A_Index = 1)

				msgbox first

		}

	}

}

[guest3456]

lol obv you use discretion for something so subjective

[rbrtryn]

I tend to follow about 90% of his suggestions in my code. I only use a four-space indentation though. Not because I think it's right or better, it's just what I've always done. Eight spaces just looks ... weird.

[quote name="Chapter 1]The answer to that is that if you need more than 3 levels of indentation, you're screwed anyway, and should fix your program.[/quote][quote name="fragman"]I tend to disagree, atleast for an example like this:

class test
{
	f()
	{
		loop 10
		{
			if(A_Index = 1)
				msgbox first
		}
	}
}

[/quote]
Well, I wouldn't count the first two indentations as part of the 3-indentation "limit". The statements in the loop would be the first indentation I would count.

[girlgamer]

Coding style guidelines are very individual and much depends on who the code is going to be used by or produced for. Indentation style is one of the more personal choices whether it's 3 spaces or 5 spaces or 8 spaces all depends on the level of readability and page format you want to convey. Personally i like a tab that is 4 spaces for compactness but that can vary by circumstance. Another visual indentation style i often use is when indenting the body of a subroutine or function to make the routine name more visible when scanning through the code

SubroutineName:
    MsgBox,0,,This is msg box 1
    MsgBox,0,,This is msg box 2
    return

this form of indentation helps me quicky identify where subroutines begin and end in my code. Especially in longer pieces.
Another form of styling is the naming conventions for variables, subroutines and functions. Occasionally i will use something called Hungarian Notation to help me remember what a given routine, function or variable's purpose is http://en.wikipedia....garian_notation this can be handy if not overdone.
Whether to leave in debugging code or not and the extent of errorchecking for boundary cases is also a style guideline. Code generalization and routine factoring are also style issues as well.
If i were to give any advice at all, I'd say pick a simple subset of styling conventions and stick with them for all your projects. Start with indentation and code factoring and try to keep your code as simple as possible given the job you need to do. The principle of Occam's Razor http://en.wikipedia....i/Occam's_razor is an important concept to apply to any code you write. And try to make your code as re-usable as possible to help you keep from having to reinvent the wheel every time.

[cheochi]

Useful information shared...Thanks

[FischGeek]

I follow some of those guidlines. However, I use the indentation that is defaulted in Scite4AutoHotkey. So, however many spaces that is. However, I do tend to use OTB for my functions.

[guest3456]

Do not add spaces around (inside) parenthesized expressions. This example is
*bad*:

s = sizeof( struct file );

not so sure i agree here

i've been working on my code and was finding that its much easier to read if () statements with function calls inside if there is a space such as

if ( isMyFunctionTrue(param1, param2) )

[rbrtryn]

i've been working on my code and was finding that its much easier to read if () statements with function calls inside if there is a space such as

if ( isMyFunctionTrue(param1, param2) )

Since a function follows the if, you don't need the outside parentheses at all.

In addition, the open-parenthesis may be omitted entirely if the first item after the word "if" is a function call or an operator such as "not" or "!".

if isMyFunctionTrue(param1, param2)

[guest3456]

yea i know that, i've tried that as well, but i like to enclose all my ifs in parenthesis not only to standardize the use of expression-if but also because i find it easier to read (pradoxically i know)

[IsNull]

yea i know that, i've tried that as well, but i like to enclose all my ifs in parenthesis not only to standardize the use of expression-if but also because i find it easier to read (pradoxically i know)

Me too - AHK has too many special handlings when parenthesis are omitted that I tend to use them always. In v2 this might change, as a if will always be followed by an expression.

Some other rules I use - personally but also enforce in teams, no matter what language used:

[*:2mm0qmes] Good readable Variable names / Method names (no abbreviations, no one-char names; exception: i,j for counters)
[*:2mm0qmes] Method Line-Count should fit on a single screen. Max 3 nested Code-Blocks. (=> create new Methods where the code is "out-sourced")
[*:2mm0qmes] Never ever have redundant code. Sounds obvious, but some people don't get it.... they copy 30lines of code, and change one single thing and generate lot of redundant overhead

[Scoox]

I have a question regarding the user of upper/lower case in AHK.

Unlike C, AHK is case-insensitive, therefore it boils down to personal preference whether to use upper or lower case. I find that capitalizing the first letter of each word not only aids readability, but also saves space:

IfWinActive that's nice
ifwinactive had a rough day?
if_win_active underscores = more horizontal space used

After using AHK for nearly three years, it is clear to me that most coders here favour capitalization, and so does the AHK help. Then why is it that many of these people choose NOT to capitalize certain keyboards such as if, else, return, while, but do capitalize most other keywords?

Personally I capitalize everything and use underscore to separate an acronym or a single letter from a word e.g. A_PriorHotkey or OSD_Message so that the first letter of the next word is not mistaken as being part of the preceding acronym.