Jump to content

Sky Slate Blueberry Blackcurrant Watermelon Strawberry Orange Banana Apple Emerald Chocolate
Photo

Is This Use of Brace Indentation Discouraged?


  • Please log in to reply
38 replies to this topic
Azerty
  • Members
  • 72 posts
  • Last active: Jan 16 2009 10:08 AM
  • Joined: 19 Dec 2006
What a pity...

Any coder will continue to code his own way...

Sorry guys :wink:

BoBo¨
  • Guests
  • Last active:
  • Joined: --
Where 'his' means 'BoBo' ergo --> BoBoStyle :twisted:

Piz
  • Members
  • 43 posts
  • Last active: Oct 26 2009 08:55 PM
  • Joined: 15 Feb 2008
I developed my own style which I call OTIS™ - the One True Indentation Style. It violates a whole bunch of Guest's rules, so he wouldn't like it at all. But it's consistent, easy to read (IMNSHO), and works unchanged for every language I've ever used - in the approximately 25 years I've been using it I've yet to encounter a language element that breaks it.

Speaking only for myself, I can't stand OTB. I find it as unreadable as Guest apparently finds anything that's not OTB. And I disagree with many of the other "suggestions" Guest makes. Of course, I'd never ask anyone else to change their own style to suit me. Posted Image

jaco0646
  • Moderators
  • 3165 posts
  • Last active: Apr 01 2014 01:46 AM
  • Joined: 07 Oct 2006

I can't stand OTB.

I agree. I find it much more difficult to read.

Piz
  • Members
  • 43 posts
  • Last active: Oct 26 2009 08:55 PM
  • Joined: 15 Feb 2008

1) Comment always. A great place for comments is the opening brace in OTB style.

Do you mean non-OTB? I don't like to comment next to OTB style braces as it seems to obscure them.

2) Don't forget to Return. A nice place for Return is immediately following the closing brace of a block.

I think it is misleading to use braces with labels for the same reason that return is required: the braces do nothing more than cause AutoHotkey to unnecessarily recurse. (Line::ExecUntil() recurses for each {, returning at }, but execution continues to the line after } anyway.)

If you want to use braces in situations like this (and I do, to take advantage of "find matching brace" capabilities in editors), in AHK you can use ";{" and ";}":

label:
	;{
	code
	;}
Whether you put "return" inside or outside those braces is a matter of preference. I always put it inside.

Piz
  • Members
  • 43 posts
  • Last active: Oct 26 2009 08:55 PM
  • Joined: 15 Feb 2008

I can't stand OTB.

I agree. I find it much more difficult to read.

My rationale for the way I use braces and other block delimiters (such as BEGIN/END in Pascal - not that I've used Pascal lately ;)) comes from the notion that the delimiters belong to the block and not to the "containing" statement (if/else etc.). For example:

if (condition)
	statement
where "statement" can be either a single statement or a block. Therefore, for single statements:

if (condition)
	single-statement
Or, for blocks, which as I stated are special cases of a statement:

if (condition)
	{
	block contents
	}
Note that the first case could also be:

if (condition) single-statement
in languages that permit it, but blocks should always take the indented form, for the simple reason that multiple statements don't belong on the same line except in (rare, IMNSHO) special cases (and in those cases there must, of course, be statement delimiters like ',' in AHK - though there it could be argued that those aren't multiple statements but another kind of single statement).

On the other hand, in languages like Visual Basic, the delimiters belong to the containing statement and not the contained lines, so the indentation should be (again using IF as an example)

IF condition THEN
	statements
ELSE
	statements
ENDIF
I've seen this:

IF condition
THEN
	statements
ELSE
	statements
ENDIF
which I would render as

IF condition
	THEN
		statements
	ELSE
		statements
	ENDIF
although this is incorrect to me, because ELSE isn't a block delimiter but an "equal partner" to IF, so it must be indented to the same level as its corresponding IF as in the first case above. Of course, that would be

IF condition
	THEN
		statements
ELSE
	statements
ENDIF
in which case there's nothing corresponding to THEN (which is here a block beginning delimiter with no corresponding closing delimiter), and ENDIF is sort of in limbo - does it close the IF-ELSE or the second "block?" The answer is that THEN is part of the IF line, not a block delimiter, and ENDIF makes up part of an IF-ELSE-ENDIF structure. Thus the first case above is correct.

I see OTB as some sort of bizarre mixture of the C and Visual Basic styles, that follows the rules for neither. It's never made sense to me.

Micahs
  • Members
  • 463 posts
  • Last active: Mar 01 2013 06:01 AM
  • Joined: 01 Dec 2006
I find this style compact and highly readable:
flatulate(fart)
{
	global
	If(fart = smelly)	;in case of emergency
	{	DispenseAirFreshener = 1
		BreatheDeeply = 0
	}
	Else
	{	BreatheDeeply = 1
	}
}
Of course it looks better in SciTE.

My personal rules:
[*:2qism7oy]Anything contained within a sub or function is indented.
[*:2qism7oy]Ditto for anything within an If or Loop.
[*:2qism7oy]I hate the OTB style - I find it hard to read. I don't use it. I prefer the braces to line up - For me, it makes it easier to see the flow of the script.
[*:2qism7oy]I like the ()s in an If statement - except where impractical.
[*:2qism7oy]Spaces around operators make it easier for me to read.
[*:2qism7oy]Multi-word variable names with caps make deciphering easier.
[*:2qism7oy]Lots of comments!
But rules are made to be broken...
Posted Image

dodenonnonisos
  • Members
  • 7 posts
  • Last active: Feb 02 2011 09:08 PM
  • Joined: 17 Apr 2008
Wouldn't it be great if somebody made an AHK-script to reformat and beautify another AHK-script according to the different preferences you have discussed in this thread?

It could be with a nice interface which let you chose among options like:

Formatting:
(x) Use } else {
( ) Put brackets on a row by itself

Spaces:
(x) Remove unnecessary spaces
( ) Add spaces to make script more readble

Expressions:
[x] Put parenthesis around expressions

e t c... ;)

TodWulff*
  • Guests
  • Last active:
  • Joined: --

Wouldn't it be great if somebody made an AHK-script to reformat and beautify another AHK-script according to the different preferences you have discussed in this thread?

It could be with a nice interface which let you chose among options like:

Formatting:
(x) Use } else {
( ) Put brackets on a row by itself

Spaces:
(x) Remove unnecessary spaces
( ) Add spaces to make script more readble

Expressions:
[x] Put parenthesis around expressions

e t c... ;)


Take a peek at Auto-Syntax-Tidy. From the script:

;Change indentation and case of commands according to syntax
;by toralf & hajos
;requires AHK 1.0.44.09
;www.autohotkey.com/forum/topic7810.html