[webkit-dev] Code clean up and compiling on 10.3.9

David Storey storey.david at gmail.com
Sat Jun 25 15:03:50 PDT 2005


Hi,

First I'd like to quickly introduce myself.  I'm David, from Newcastle, 
England, and have recently graduated from a MSc in Internet and 
Distributed Systems, at the University of Durham.

I'd like like to get involved in WebKit development to gain some much 
needed experience, and help improve something I use frequently and that 
I'm interested in.  As I've limited knowledge of C/Obj-C (i'm mainly a 
Java developer), I though one of the best places to start would be on 
the code clean up and documentation.  Is there any timeframe when or if 
WebKit will compile on 10.3.9?  I don't have access to Tiger and can't 
afford to buy it, so I can't make any changes until it compiles.  I 
don't have access to the Tiger DVD to get the missing header files 
either.

At one stage JavaScriptCore compiled on Panther (it fails again now), 
so I decided  to have a go at cleaning up that part of the project.  
Unfortunately it took two days to clean up every class, and by that 
stage when I performed the regression test, there were a number (even 
though I didn't make any real changes).  It seemed that it actually 
passed many more than the master copy though.  I thought I would submit 
the changes anyway, but i followed the steps on the site to produce a 
patch file, but it only created a blank file.  I'm not sure if that was 
something to do with the app not compiling, or if I did anything wrong. 
  Most the changes were just white-space changes.

While working on the code cleanup there were a number of areas that 
different programmers implemted differently which were not covered by 
the style guidelines.  Maybe there should be some guidelines to cover 
these:

1. Should first level statements after the method name be indented 4 
spaces too?  mostly they are indented twice  e.g.

methodName(param)
{
     statement;
}

instead of

methodName(param)
{
   statement;
}

2.  Case statements do not seem to be mentioned.  some use {} and some 
don't, even in the same switch block.  Should all case statments have 
or not have braces?  if they should, should they be like :

}  case CSSSelector::List: {

OR

case CSSSelector::List: {
	statemnts;
}
case ...

3.  Braces are not mandatory when the statements are only one line for 
'if and 'for' etc.  Sometimes no braces are used and sometimes not.  
Should there be a guideline to keep this consistent.  Personally I 
prefer always using braces, as it is clearer, but not everyone may 
agree.

4.  There should possibly be a guideline for how many spaces to indent 
when wrapping a line that is too long to fit on one line.

5. Often code goes on for pages without any line breaks at all.  
Possibly there should be a guideline on when to leave a line space 
between blocks of code, such as leaving a line before a return 
statement at the end of a method or between and if or for block.

6.  Not really knowing C, i wasn't sure what the '#if apple changes' -- 
and other such  if constructs that xCode highlights in red -- are for?  
I wasn't sure if these should be indented like a normal if statement?

7.  There are no guidelines for casting.  I personally prefere:

var = (cast) methodName(param, otherParam);

but often they were formatted without the space, such as :

var = (cast)methodName(param, otherParam);

I think that is it for the moment.  sorry for going on, but after 
spending two days at code reformatting, I noticed a few things.

Thanks for your time, hopefully in the future  will be able to make 
some contribution to the project,

Regards,

David

------------------------------------------------------
David Storey
University of Durham
------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 3799 bytes
Desc: not available
Url : http://lists.macosforge.org/pipermail/webkit-dev/attachments/20050625/b769543e/attachment.bin


More information about the webkit-dev mailing list