Re: Code formatting

Well, standards are nice, but when they would hinder working on the 
code, I know
where my priorities ly. Some of these recommendations seem rather dated.
E.g almost everyone nowadays has a display that can handle over 80 
characters (often even
more than double that), and it would be very counter-productive for me 
to constantly
engage in excessive scrolling while leaving the right-hand half of my 
display entirely blank.
Especially since I work on a Linux VM on a small laptop, which does not 
leave very much
vertical space to display actual text if you subtract all Windows task 
and menu bars,
and then all Linux task and menu bars, and then all the editor's menu 
bars...

This is why I also abhor styles that are vertically verbose, using many 
nearly empty
lines. I also don't like the custom of an intermediate indent for the 
braces surrounding
the body of control statements; it needlessly doubles the number of 
different indents,
just making the code more difficult to read. I don't think there is any 
disadvantage
to writing "if(A) B = C;" or even "if(A) { B = C; C = D; D = B; 
continue; }" on a single line,
as long as the indent makes it obvious that there is no 'body' below the 
if(), and
the line is not significantly longer than surrounding lines. It saves a 
lot of lines,
increasing the amount of code I can view at once significantly. Indents 
are supposed
to make it easier to see where the body of control statements end. Not 
being able
to see the end of the body and the control statement at the start at the 
same time
completely defeats that purpose. The first priority is to get them in 
view simultaneously,
and only then it becomes of any relevance how the indentation looks. The 
GNU coding
standard seems VERY counter-productive in this respect.

As I seem to be pretty much the only person that intensively works on 
the code,
it seems madness to make my live harder on the purely hypothethical premise
that someone that might want to work on it too would only have an 
80-character-wide
display or would like to code on a phone.

An unfortunate layout defect in the current code is inconsistent use of 
tabs and
spaces for indenting, combined by the fact that lots of code lines have 
been generated
through MS WordPad, in which a Tab is equivalent to 6 spaces, rather than 8.

Nice joke about 'code review'; we of course have none of that at all.

It is a bit counter-productive to spend time on cleaning up code that is 
still heavily
being worked on by someone that doesn't really understand what is needed
to make things work as desired, so that 90% of the time any new code would
be deleted in the next revison anyway. Especially the GTK code such as the
mentioned xoptions.c suffers from that. I still would not dare to claim 
I know
how to use GTK, but most of the code I contributed to xoptions.c was written
when I knew 10 times less. It would really need a complete re-write in 
the face
of this increased understanding.

But time to me is a scarce resource, and XBoard is consuming (far) too 
much of it
as it is. Making code changes that do not result in any increase of 
functionality
are lower on my list of priorities than other things that I also do not 
get to.

If any non-functional changes to improve the code are to be made, I 
think that
improvement of the used data structures and algorithms would be much more
important than layout changes. Some things really work in an awful way now
(e.g. castling rights).

H.G.

Op 4/7/2016 om 6:42 AM schreef Arun Persaud:
> there are the gnu coding standards which we should be using for XBoard
>
> http://www.gnu.org/prep/standards/
>
> Would be great to have these as a pre-commit hook in git, so that only
> commmits are allowed that follow the standard. That way the code should
> get slowly better over time ;) Unfortunately, I don't know how to set
> this up. If anyone knows how to do this, I think it would be a great
> idea to implement this. Would be great to have that pre-commit hook on
> savannah, so that people can't push changes that don't follow the
> guidelines, but also as a local pre-commit hook, so that it is easy to
> already generate commits locally that would follow those standards.
>
> Any ideas?
>
> Arun
>
>