[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).
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
Re: [XBoard-devel] Code formatting, Thomas Adam, 2016/04/06