sh coding style

[johnbock]

I would prefer defining one use case instead defining a use case and many exceptions to it. After all, we are trying to make the code uniform and thus easier to read and understand.


What do you guys think of the exports and variable assignment in one line?

export x=${x:=720}

Define x when x is not set or null (empty).

 

[buehmann]

BUT, you don't need it here:

[  -z $MYVAR  ] &&  echo zero

Around $MYVAR? Of course, you do (well, it depends on the possible values):

# MYVAR=". -o -n ."
# [ -z $MYVAR ] && echo zero
zero

Andreas

 

[Silent-Tears]

I think the discussion about how to use a shell is really out of topic here. I personally though, this discuzssion is about the coding style we shpould use in freetz, is it?

IMHO i think it ist really usedful if it does what we expect. All other changes are not really nessessary, or even not needed at the moment.

Or should a new coding style be a point of interest for the roadmap to Freetz-1.0?

Then we should define a "standard" and channge all the packages/scripts an so on to follow these coding conventions, but - once again - we do not discuss the functionality of ther above code-snippets.

greetz

cinereous

 

[McNetic]

This is my opinion:
The sh code style is not release-critical. It is also not necessary to change all scripts in one big step.

On the other hand, it sensible to make changes, as it makes the code more readable and maintainable, plus it can save performance in some places.

But as far as I can see, the discussion is still about code style, as some stylistic changes may also have an impact on functionality.

Back to topic: I think we should use quotes (") anywhere they could be necessary, even if we know, that at the moment, the quoted part does not expand to more than one word (for example [ -z $MYVAR ] should always be [ -z "$MYVAR" ]). If we do this, we avoid creating (hardly maintainable) side-effects from later code changes.

 

[RalfFriedl]

I agree.

Better safe that sorry. Quotes don't hurt (except for the few bytes of memory), and better some unnecessary quotes than some important quotes missing.
Also better some unnecessary quotes than having to think about every quote whether it is necessary or not.

I also think it is easier to read

if [ "$VAR" = "yes" ]

although the quotes around "yes" are not necessary.
And it is certainly much better than this style:

if [ x$VAR = xyes ]

 

[johnbock]

A little recap

I think we've discussed command substitution, variable testing and assignment and I hope that we can agree to:

Variable Assignment
shall be written without single or double quotes

variable=yes
variable=$(<command>)

unless required

variable=" something else "

Variable Testing
while testing a variable, it shall be enclosed in double quotes

[ -z "$variable" ]
if [ -z "$variable" ]; then

The most concise test expression should be used

[ -z "$variable" ]

and not

[ ! -z "$variable" ]

While testing against literals double quotes shall never be used. Single quotes shall be used as required

[ "$variable" = yes ]
[ "$variable" = '$this is a literal' ]

Command Substitution
shall be written with the parenthesis style.

$(<command>)
for variable in $(<command>); do

================================
Please intelligently comment on the above so that we can jot this down and move on to undiscussed topics

 

[cuma]

Quotes don't hurt (except for the few bytes of memory), and better some unnecessary quotes than some important quotes missing.
Also better some unnecessary quotes than having to think about every quote whether it is necessary or not.

That' right. Freez should mainly do what's expected from it. If there are many (unnessesary) changes, there could be many errors.
A "How to have a good coding style" Guide would be nice

 

[olistudent]

Perhaps somebody can write this down in the trac wiki?

Greets Oliver

 

[johnbock]

Perhaps somebody can write this down in the trac wiki?

Greets Oliver

Shouldn't we wait until we get some kind of consensuses?

 

[McNetic]

I adapted the solaris shell style guide to our needs and wrote a basic wiki page as a draft. Some parts are still to be discussed.

 

[johnbock]

looks super

I agree to true instead of colon when true is a built-in.

I would like to see the paragraph numbers at the paragraphs too.

Thanks for the initiative, just fantastic...

 

[McNetic]

I would like to see the paragraph numbers at the paragraphs too.

I had them first; but the toc function of trac inserts it's own numbers. I don't know how to change this behaviour.

 

[olistudent]

Wenn mir jemand das Problem auf deutsch erklärt kann ich vielleicht versuchen es zu lösen?

MfG Oliver

 

[McNetic]

Das Inhaltsverzeichnis von Trac fügt automatisch eine Nummerierung ein, die jedoch bei den einzelnen Überschriften nicht vorhanden ist. Wenn man da manuell eine einfügt, ist sie beim Inhaltsverzeichnis doppelt.

 

[olistudent]

Hm, da wüßte ich jetzt nicht wie man das beheben könnte...

MfG Oliver

 

[johnbock]

commenting

While reviewing the style wiki I found an open question in the Commenting Section.

Discussion? ... Place single-line comments in the right-hand margin. Use an extra '#' above and below the comment in the case of multi-line comments:

My thoughts on single line comments:

• should neither be prefixed nor suffixed by an extra '#'.
• should not be placed in a right-hand margin, rather always in a separate line preceding the code in question.

reasoning to 2)
we would have to agree to the position in the right-hand margin to put the comment

 

[buehmann]

Außerdem lässt sich so ein einzeiliger Kommentar einfacher zu einem mehrzeiligen erweitern. Und der Kommentar verrutscht nicht, falls die kommentierte Codezeile verändert wird.

Ich persönlich mag deshalb Kommentare am Ende einer Codezeile überhaupt nicht. Also Daumen hoch für Punkt 2. Punkt 1 ist für mich auch klar: Einzeilige Kommentare sollten wirklich einzeilig sein.

Andreas

 

[McNetic]

Ich würde dem auch zustimmen.

 

[ao]

Hi, guys! This discussion and also the corresponding wiki are really great to learn shell coding. Thank you!