| View previous topic :: View next topic |
| Author |
Message |
Azerty
Joined: 19 Dec 2006
Posts: 58
Location: France
|
 Posted: Sat Mar 22, 2008 6:42 pm Post subject: |
 |
|
What a pity...
Any coder will continue to code his own way...
Sorry guys  |
|
| Back to top |
|
 |
BoBo¨
Guest
|
| Posted: Sat Mar 22, 2008 7:05 pm Post subject: |
|
|
Where 'his' means 'BoBo' ergo --> BoBoStyle  |
|
| Back to top |
|
|
Piz
Joined: 16 Feb 2008
Posts: 46
|
| Posted: Sun Mar 23, 2008 11:12 pm Post subject: |
|
|
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.  |
|
| Back to top |
|
|
jaco0646
Joined: 07 Oct 2006
Posts: 459
Location: MN, USA
|
| Posted: Mon Mar 24, 2008 12:23 am Post subject: |
|
|
| Piz wrote: | | I can't stand OTB. |
I agree. I find it much more difficult to read.
_________________
http://autohotkey.net/~jaco0646/ |
|
| Back to top |
|
|
Piz
Joined: 16 Feb 2008
Posts: 46
|
| Posted: Mon Mar 24, 2008 2:16 am Post subject: |
|
|
| Lexikos wrote: | | Quote: | | 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.
| Quote: | | 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 ";}":
Whether you put "return" inside or outside those braces is a matter of preference. I always put it inside. |
|
| Back to top |
|
|
Piz
Joined: 16 Feb 2008
Posts: 46
|
| Posted: Mon Mar 24, 2008 2:47 am Post subject: |
|
|
| jaco0646 wrote: | | Piz wrote: | | 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:
| Code: | if (condition)
statement |
where "statement" can be either a single statement or a block. Therefore, for single statements:
| Code: | if (condition)
single-statement |
Or, for blocks, which as I stated are special cases of a statement:
| Code: | if (condition)
{
block contents
} |
Note that the first case could also be:
| Code: | | 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)
| Code: | IF condition THEN
statements
ELSE
statements
ENDIF |
I've seen this:
| Code: | IF condition
THEN
statements
ELSE
statements
ENDIF |
which I would render as
| Code: | 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
| Code: | 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. |
|
| Back to top |
|
|
Micahs
Joined: 01 Dec 2006
Posts: 318
|
| Posted: Tue Mar 25, 2008 1:57 pm Post subject: |
|
|
I find this style compact and highly readable:
| Code: | 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:
- Anything contained within a sub or function is indented.
- Ditto for anything within an If or Loop.
- 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.
- I like the ()s in an If statement - except where impractical.
- Spaces around operators make it easier for me to read.
- Multi-word variable names with caps make deciphering easier.
- Lots of comments!
But rules are made to be broken...
_________________
Last edited by Micahs on Wed May 07, 2008 4:04 pm; edited 1 time in total |
|
| Back to top |
|
|
dodenonnonisos
Joined: 17 Apr 2008
Posts: 1
|
| Posted: Wed May 07, 2008 2:56 pm Post subject: |
|
|
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... ;) |
|
| Back to top |
|
|
TodWulff*
Guest
|
| Posted: Wed May 07, 2008 3:31 pm Post subject: |
|
|
| dodenonnonisos wrote: | 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:
| Code: | ;Change indentation and case of commands according to syntax
;by toralf & hajos
;requires AHK 1.0.44.09
;www.autohotkey.com/forum/topic7810.html |
|
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Register
Profile
Log in to check your private messages
Log in
