[Swan] tabstops

[Philippe Vouters]

To help on this debate, I always run Linux Fedora aterm (80 columns 
wide, black background) and run vim when I edit any file even when 
editing a pure OpenVMS (totally non Unix) shell script.

When I was developing on Libreswan, I was almost always running 4 
aterm's in the same screen. The aterm's were large enough without them 
being too wide, so I could constantly have four different views onto 
four different things on my 15 inches video terminal. With vim colouring 
very well and especially noticeable with a black background, I had lots 
of comfort leading me to high productivity at low effort costs but 
coding or understanding the pluto logs.

About the tabbing rules, my preference goes to code or text which does 
not wrap around when tending to be over 80 columns width.

I had once to work on a Windows Visual Basic source file which had 
extremely long statement onto the same line. One had to use the 
horizontal scroll bar to view the whole statement. Needless to tell this 
code was as is very difficult to understand. Hence my very first task 
onto it which been to reorder the statements to suppress any horizontal 
scroll bar need.

Another thing I prefer when reading C code is low use of several if then 
else levels. As an example of what I prefer, look at current Libreswan 
routine parser_load_conf inside ./lib/libipsecconf/parser.y that I 
rewrote, entirely keeping the initial logic, and consider how it 
previously was. With my rewrite I no longer need to move the cursor onto 
{ or } and key press % to know where the then or else block of the if 
ends up. The C goto or a quick return statement when appropriate are 
very welcomed in such case to add clarity to a code and greater 
understanding comfort for the maintainer.

About Hugh's raised discussion upon the STREQ Libreswan macro, I 
consider that strcmp is sufficiently known by most if not all C 
developers that there was no actual need to add a macro for it. STREQ is 
not natural for C programmers whereas strcmp is rarely unknown, except 
to C newbies. This STREQ macro looks to add useless complexity without 
evident clarity to the new comers to a project.

Regards to everyone,
Philippe

Philippe Vouters (Fontainebleau/France)
URL: http://vouters.dyndns.org/
SIP: sip:Vouters at sip.linphone.org

Le 15/02/2013 01:24, Hugh Daniel a écrit :
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA384
>
> To: swan at lists.libreswan.org
> Cc: "D. Hugh Redelmeier" <hugh at mimosa.com>
> Subject: Re: [Swan] tabstops
> In-Reply-To: Your message of "Thu, 14 Feb 2013 16:09:31 EST."
>               <alpine.LRH.2.02.1302141533450.3838 at redclaw.mimosa.com>
> Reply-To: hugh at xisp.net
> Errors-To: hugh at well.com
> OpenPGP: url="http://www.toad.com/hugh/0x566974947B141411"
>
>    Emacs will read and ask to process some very carefully formatted
> comments at the beginning and ends of files to set local editing
> conventions or what not.  In this case it's trying to say TAB is evey 4
> column and otherwise use the defaults from "pluto" if you have them
> somewhere (basically a macro function).
>
>    While I personally find the TAB mess true insanity, for DECADES a tab
> ment every eighth column in WAY more then just Unix, and I have stuck
> with that not because I like it, but it was very very standard.  Frankly
> these days I just make very wide windows when I need them.
>
>    For general education here is the page on what Emacs can do:
>
> http://emacswiki.org/emacs/LocalVariables
> 	# Both forms are described on this page
>
>    Sadly I am going to have to suggest that rather then get into a time
> wasting argument, for the 10,000'th time, that someone(!) needs to just
> DECLARE one or the other of the two major solutions (always 80 chars
> wide code & tabs are every 4th column vs. try for 80 chars wide code,
> wider if needed, and every 8th column tabs) standard for our project.
>
>    I am not sure what the rest of the Linux Kernel is using, but it seems
> likely we should use that, even if it seems silly to some of us.
>
>    The tools are such that conversion is trivial these days, emacs can do
> it in it's sleep. In fact you _could_ have your editor show you the code
> in which ever format you like and then always convert to the project
> standard as part of the check in process, which is why I am rather blase
> on the subject any more.
>
>    How often do we really need hand crafted core formatting any more?
> Remember this code will likely outlive both your current notions of good
> style AND you! Just like all that dammed COBOL code with BCD data
> fields...
>
>    Oh and hi folks!
>
> 		||ugh Daniel
>
> -----BEGIN PGP SIGNATURE-----
> Comment: For the matching public key, finger the Reply-To: address.
>
> iQCVAwUBUR2ABVZpdJR7FBQRAQkTuQP/bZk85Po6GXAxLvsXIyVjeqBTViqe3uty
> i9aU66uTp/CDdmVyIeg3CvZxohtJjqcVmbR/Oq3NNtHBm0FgzayYLoITL2I2U7Fq
> GyEC5EcF7xR5aUEyGw8nUeFzQ7PLVPK3waQ0lTQHKZy1x6tT497r6XmvnxQ4RAl7
> 8oOj6AnP1SA=
> =WTmJ
> -----END PGP SIGNATURE-----
> _______________________________________________
> Swan mailing list
> Swan at lists.libreswan.org
> https://lists.libreswan.org/mailman/listinfo/swan
>