bug-gnubg
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug-gnubg] Coding Style Revisited - A decision


From: Michael Petch
Subject: [Bug-gnubg] Coding Style Revisited - A decision
Date: Fri, 14 Jun 2013 12:34:54 -0600
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6

Howdy all,

A number of months back I made a general inquiry about people's feelings
about reformatting all of our code.

I am revisiting that and I'd like to make a final decision. I read all
the responses and have tried to come to a reasonable compromise.

First off, I originally envisioned making the change module by module as
people make alterations. After dealing with formatting issues the last
number of months between files that vary considerably, I am in agreement
with Guido Flohr that we should do it at once. You may not necessarily
realize that a file has been reformatted or not, and it is cumbersome to
switch between different styles in an editor when files may be different.

I think it is more beneficial to make sweeping changes to all the .h and
.c files (and rebuild the pot files for language processing). I am
considering tidying up the Python files with 4 character tabs converted
to spaces as well (with something like TidyPython)

I intend to use:

indent -kr -l120 -fc1 -sc -nut -psl

K&R is the style found in "The C Programming Language" books. It uses
these settings with indent:

-nbad -bap -bbo -nbc -br -brs -c33 -cd33 -ncdb -ce -ci4 -cli0
-cp33 -cs -d0 -di1 -nfc1 -nfca -hnl -i4 -ip0 -l75 -lp -npcs
-nprs -npsl -saf -sai -saw -nsc -nsob -nss

This uses k&r formatting (see indent man page for information) limits a
line to 120 characters, reformat all the comments (even ones starting in
column 1), place an asterisk at the beginning of each line of a
multiline comment, convert indentation to replaces tabs with spaces, and
the names of  functions  being  defined are  placed  in column 1 - their
types, if any, will be left on the previous lines (this style is heavily
used in the code already)

K&R uses 4 spaces for a tab level.

This won't please everyone, but I think it is likely the best compromise.

The only thing I am wondering is if anyone has a preference about space
being after an open parentheses and a space before a closing
parentheses. This seems to be the other big stylistic difference in
modules. The settings I have given above do not use the extra space, and
I have a preference for a "no" on that point, but its not a big deal to
me personally.

I'd like to make this change to CVS on Saturday, and want anyone who may
be making changes to files aware of it.

If there are concerns, questions etc, please let me know.

-- 
Michael Petch
GNU Backgammon Maintainer / Developer
OpenPGP FingerPrint=D81C 6A0D 987E 7DA5 3219 6715 466A 2ACE 5CAE 3304



reply via email to

[Prev in Thread] Current Thread [Next in Thread]