Why?? (prog question)

[Polytropon]

On Tue, 31 Mar 2009 08:54:17 -0700, Gary Kline <kline at thought.org> wrote:
> > 1. Use the tab character for indentation. You can set its
> >    length with your favourite editor (e. g. mcedit: F9,
> >    Options, General; joe: ^TD). Don't waste with spaces.
> 
> 	Ja, been doing this since 1978.  Does anybody hit space-key 
> 	8 times!?

I've seen "corporate guideline" for indentation = 10 spaces.
Used ^TD8 and then finally replace tab -> '          '. :-)



> > 2. The main() function should be declared as
> > 	int main(int argc, char *argv[])
> >    or
> > 	int main(int argc, char **argv)
> >    Note that it's returning (int). Use this functionality.
> 
> 	I've come to prefer the *char argv[] ...  I didn't use the formal int
> 	return because this was supposed throwaway code.  (Going on years now
> 	tho, so ... my-bad.)

The standard assumption of the return code is (int), so if
it's not declared, it's (int) anyway.



> > 4. Use the predefined return codes, don't hardcode them.
> >    FreeBSD has EXiT_SUCCESS and EXIT_FAILURE, they're for
> >    maximum compatibility (such as with Linux). There are
> >    more exit codes for differentiation, but they're specific
> >    to FreeBSD, as far as I know.
> 
> 	This I did not know.  I have a prefab include file with a bunch 
> 	of my own similar #defines.  Wow, great!

FreeBSD defines additional exit codes to specify the reason for
exiting more precisely in /usr/include/sysexits.h - for your
example, exit(EX_USAGE); would be a good exit code.

I don't know how far this is adopted in Linux, but I think you
can only use the C99 two standard return codes.

>From "man 3 exit":
     The C Standard (ISO/IEC 9899:1999 (``ISO C99'')) defines the values 0,
     EXIT_SUCCESS, and EXIT_FAILURE as possible values of status. 



> > 5. This is highly debatable: Use a good style for { and }.
> > 
> 
> 	Well, you're using the K&R { }; but for me, the "Ingres"
> 	style [[ yes, it was invented by someone else ]] gets my vote.
> 	I scan
> 	{
> 	  and
> 	}
> 
> 	more easily.  6 of one, half-dozen of another... .

In fact, I'm sticking to the concept that only the highest level
of "code groupers" deserve a new line {: these are functions in
C and class methods in C++. Everything else has the { appended
(after a space) to the construct that causes the {. So if you find
a }, you only need to look up. It's obvious that a } is caused
by a {, but you want to know the construct that made it appear,
for example if(), while(), a struct definition or something similar.
With this concept at hand, looking up will make you find this
construct in question at the first glance.

You could see this in the example.

But as we'll all agree, this is a thing of individual preference.


> > Here is the program again, with some stylistic modifications
> > and the "correct" (read: recommended, usual) exit code handling:
> 
> 	I'll swipe this.  I use this code with openoffice and abiword
> 	because I compose with vi;  but I almost always forget to run 
> 	my text thru joinlines and have to quit the word processor, run
> 	jlines <foo> bar; mv bar foo; then restart the word processor.
> 	I figure that I've spend several centuries of my lifetime messing 
> 	with jlines, so i'm overdue for doing it right....

I think OpenOffice has the function Input - from file (at least
the german version has: Alt-E D = Einfügen Datei). This makes it
easier to incorporate text from an external file.


-- 
Polytropon
>From Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...