Syntax and naming conventions?

[Xeilous]

What sort of naming conventions and syntax do you use(if any) when writing your code. I find myself changing portions of my code until "I like it."

Just wanting to get some different perspectives here, because I see all sorts of variations out there. I know Autohotkey is case-insensitive, and so it doesnt usually matter how you write things.

Variable & Function Names:
I always use camelCase
I always use the := operator, even when it's not necessary.
I always put spaces around the operators.

Code: Select all

firstName := "John"
lastName := "Doe"
firstLast := firstName " " lastName

Others:
I'll add more after I get off work, just wanted to start the discussion for now.

[nnnik]

I use camelCase for variables, methods and function names.
I use CamelCase for class names.
I always use the := operator.
I always use the . operator to combine strings.
Lately I've started to use OTB.
I use a space after every comma. I use spaces before and after surrounding brackets.
I use [] for properties even if it isn't eneccessary. I use () with new even when it isn't neccessary.

Code: Select all

functionName( argumentName1, argumentName2 ) {
	return new ClassName1()
}
functionName2( singleArgument ) {
	return 42
}
class ClassName1 {
	property[] {
		get{
			return "Hello" . " World" . "!"
		}
		set{
		}
	}
}

[tidbit]

never use := %
:= is an expression.
single % forces a non-expression to an expression.
since := is an expression, single % is useless.

[Xeilous]

Just noticed I did that by accident lol, typing this all out on my phone. I don't actually do the := % thing.

I think I did that because I'm so used to typing MsgBox, % varOne " " varTwo. That's where I got that from.

[Trogluddite]

Pretty much as described already for variable/function/method names. I'm not a big fan of CamelCase generally, but it seems to be the de-facto standard for AHK.

• I drop my leading braces down a line - I blame a workplace style guide from years ago where OTB was frowned upon for some reason.
• Arguments always in parentheses for functions and methods, spaces after commas but not around the parentheses
• Indent levels are two spaces.
• Double indent for a continuation line.
• Two leading underscores for anything I consider "private".
• Single leading underscore for arguments and locals (another bad habit picked up years ago. )
• Assignment operators lined up if there is any chance I'll need to column edit a run of lines.
• SCREAMING_SNAKE_CASE for "constants" (static globals.)
• Double blank lines between method and class definitions.
• Single blank lines within definitions to separate 'paragraphs' of code.
• One class per file if it's a big project.
• Endless hours of tinkering with whitespace and renaming everything umpteen times!

That's for AHK anyway. For other languages, I'll generally try to adopt what is commonly accepted if there is any kind of standard (e.g. slithering_snake_case for methods/variables in Ruby.)

[Cerberus]

Pretty much as described already for variable/function/method names. I'm not a big fan of CamelCase generally, but it seems to be the de-facto standard for AHK.

• I drop my leading braces down a line - I blame a workplace style guide from years ago where OTB was frowned upon for some reason.
• Arguments always in parentheses for functions and methods, spaces after commas but not around the parentheses
• Indent levels are two spaces.
• Double indent for a continuation line.
• Two leading underscores for anything I consider "private".
• Single leading underscore for arguments and locals (another bad habit picked up years ago. )
• Assignment operators lined up if there is any chance I'll need to column edit a run of lines.
• SCREAMING_SNAKE_CASE for "constants" (static globals.)
• Double blank lines between method and class definitions.
• Single blank lines within definitions to separate 'paragraphs' of code.
• One class per file if it's a big project.
• Endless hours of tinkering with whitespace and renaming everything umpteen times!

That's for AHK anyway. For other languages, I'll generally try to adopt what is commonly accepted if there is any kind of standard (e.g. slithering_snake_case for methods/variables in Ruby.)

I love SCREAMING_SNAKE_CASE! I think henceforth I'll USE_HIM_FOR_EVERYTHING!!!1ONEONE