> Sigh, nobody seems to read the official information. :-(
I did, and have been very worried.
> Given that it is possible to auto-migrate existing applications with
> just a few (if not single) shell command(s) and almost no manual
> action like in your quite successful case, I think it's a fair
> compromise to have the code style modified in a consistent way.
> Again, if that is a no-go for someone, the migration to 0.7 could
> still be done manually. YMMV.
I very strongly agree with Derrell in that I would want to maintain our own
coding style, which has been preserved over 15 years of development of all
sorts of programs in many different languages, with many different developers
from all over the world.
Key features include 3 spaces indent, braces are on their own lines and are
indented, function header comments in particular formats, and heavy use of
commenting with trailing comments on lines starting at column 49 (or as close
as possible if past there).
If I have this code:
if (bSet) // do we need to do this?
{ // yes, make sure about it
//
// First operation is to do this
//
CallMyFunc(); // by doing this
}
What will happen to the comments if you reformat to:
if (bSet) { // do we need to do this?
//
// First operation is to do this
//
CallMyFunc(); // by doing this
}
There is one less line for the comments. Would you throw something away? Would
you preserve the comment starting columns?
We format structures consistently (sounds a bit like Derrell). Here is an
extract taken from a class which sets up information for our protocol:
//
/** Watch a fragment */
//
FragmentDetails :
{
nType : 5,
sRequest : "f",
sRequestLong : "FragmentDetails",
nUpdateCount : 0,
dParams :
{
sFragmentID : "ff" // fragment ID
},
dResponse :
{
bOK : "fk", // 1 if OK, 0 if failure
sFragmentID : "ff", // the ID of fragment.
nFragmentTypeID : "fy", // type of fragment
If that gets rewritten to the qooxdoo standard it's going to lose a lot of
visual formatting designed to make it easier to read for maintenance. As we
don't have automatic IDE code analysis tools for Javascript yet (like: "go to
definition"), layout is important to us to aid the developer.
> This area of development would definitely need contributors to
> accomplish such a configurable custom coding style. Volunteers!?
For our 400k of Javascript code I would much rather work on the generator to
put in the options I want than spend a week fixing up all your "formatting", or
doing the migration by hand.
What's going to happen when upgrading from 0.7 to 0.8, 0.9 etc? Will it all get
changed around again?
The options I want would be:
- indent spaces or tabs (we use spaces)
- number of spaces for indents
- indent or outdent braces
- opening brace on own line or not
- preserve comments, including the starting column for
trailing comments
- layout multiple map values starting at consistent columns
However, I'm not going to be able to do that before the end of Feb.
Hugh
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
