I’ve added a section to the new wiki for us to place established policies and standards, for those submitting code to the tree.
which is to say, i’ve placed my current method of submission instructions in it, since i am unaware of any agreed to standards on coding practices.
Can i get a ruling, regarding the use of carriage returns and line feeds in executable scripts? for instance, formscript.pl is formatted ‘windows style’ and is therefore not executable on linux.
All text files for the project should have Unix-style line endings (i.e. no carriage returns). Developers who use a Windows desktop should also use a suitable text editor that respects this (last I checked, EditPad Lite was one free example).
Jeremy Wallace has been working on this as well. He has mostly been basing his Coding standard on Rod’s working style. Rod usually gets high marks for his code and a large portion of the code is his anyway.
Let’s just be careful not to make any hurdles that may lose a potential developer. In order to hook as many developers as possible, my main goals have been:
1) Get new developers to submit in the tracker, since it’s much quicker for us to test (rather than have emailed to one of us). Then get quick testing and feedback by community, which is important to keep that developer.
2) Try (note try, not require) to get new developer to perform changes on most recent CVS code. This then makes it much easier to test whether it’s a patch or a complete file.
Haven’t been stressing the carriage returns or forcing patches over files, since these are easy changes (dos2unix command) by us when we commit the code.
Of course, anybody whom has commit privileges needs to ensure they have unix-style line endings. On that note, I’d suggest emailing Mark Leeds to fix the formscript.pl script (he plans to commit a CAMOS update soon anyways).
I agree fully that not fitting with the established standards and practices should not be a reason to out of hand reject code from a new developer. I meerly want to have a set of standards code ‘should’ adhere to, so i can feel free to submit patches that fix things that don’t match.
I agree. Having the separate page for new developers will work out (don’t need to really push any standards here). Then in the policy page you created, can go to town on the coding standards.
