[Top][All Lists]

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

Re: [XBoard-devel] Code formatting

From: H.G. Muller
Subject: Re: [XBoard-devel] Code formatting
Date: Thu, 7 Apr 2016 11:09:52 +0200
User-agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1

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).


Op 4/7/2016 om 6:42 AM schreef Arun Persaud:
there are the gnu coding standards which we should be using for XBoard


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?


reply via email to

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