Re: 100+ warnings and some cosmetics along the way (issue1724041)

[Han-Wen Nienhuys]

On Thu, Jun 17, 2010 at 9:55 AM, Pap Lôrinc <address@hidden> wrote:

>> * in case you are doing cosmetic changes, can you double check that your
>> standards are part of the style guide - I recall it is not that strict in
>> many areas, and in many cases there is no real reason to choose one over the
>> other. * If there is no style guide standard, can you document the style
>> first?
>  - ouch ... I've just changed appearances that looked random or unnecessary
> (like wrappings at ~60), or one variable parenthesized returns etc. Should I
> drop all cosmetics and leave it a strict warning correction? The code won't
> evolve this way, if -though being open source- everyone wants their code to
> be
> untouched.
>

it's not that I want things untouched, it's that

* I don't want someone else to come along and change formatting details again.

* If we are doing a fixup of this, we should try to do all files at
the same time, or at least a section of files.

If we decide on a line length limit (I am fine with 100 or 80. We have
80 at google, and I find it on the short side), we should document
that and then fix all instances of it in a structured way.


> My first glance of the code suggests me (blindly) that the long long and
> double are overused (I am probably wrong here), that also being the reason
> for all those casts

Most of the casting I see is because of signed vs. unsigned, but I'll
try to take a look some time (I dont have a 64 bit machine at home).
For float vs. double, I just went with what is commonly done in the
Stroustrup and K&R book.  Since double's are native types, and we dont
use many of them anyway, I doubt you can measure a speed difference
between double and float.

Regarding 'long long', flower/include/flower-proto.hh says

  typedef long long I64;

but this is wrong, as it is not conditional on the architecture (this
code is from way before 64 bit PCs), and fixes would be welcome.

For rationals (the only place we use I64), long long (ie. 128bit
numbers) would be welcome to prevent overflow.


> (and I also think that too many preprocessor macros are
> used ... but I'm no expert, please don't take my opinion as an insult). I

What is 'too many' ? Which macros could we do without?

> variables? "Item *h", "Axis a", "Grob *g", "Real d", "Direction d" and
> "Direction which" ... how will I know what a "which" and a "d" is, when I
> see one?).

I agree with this in some cases but not in all, which is also why I
want to see more targeted commits, so we discuss specific cases.

-- 
Han-Wen Nienhuys - address@hidden - http://www.xs4all.nl/~hanwen