Re: [Wxdevide-devs] Coding Guidelines

[Tony R. <tb...@gm...>]

> What about component naming? Obviously the components have inherited
> their Delphi names but should there be a list of components and their
> "accepted" names? At the moment it is not important, but I envisage us
> continuing development, perhaps adding new dialogs, and these should
> follow the naming conventions for the rest of the project.
>
> While we are on the subject, should this be something we should add to
> wxdev-c++ initially? Offering a cbTemp1 instead of WxCheckBox1?
>

Yes, I think it's a good idea to convert the names and formatting now.


>
> > To get more feedback on the guidelines I have a
> > list of other projects guidelines. I particularly like some of the
> > ideas of the NOX project.
> >
>
> I would insist on changing
>
> Braces ("{}") which enclose a block should be aligned as follows:
>
>    if ( /*Something*/ ) // Yes!
>    {
>      i++;
>      j++;
>    }
>
>     if ( /*Something*/ ) { // Okay
>      i++;
>      j++;
>    }
>
>    if ( /*Something*/ ) // No!
>      {
>        i++;
>        j++;
>      }
>
> to
>
> Braces ("{}") which enclose a block should be aligned as follows:
>
>    if ( /*Something*/ ) // Yes!
>    {
>      i++;
>      j++;
>    }
>
>     if ( /*Something*/ ) { // No!
>      i++;
>      j++;
>    }
>
>    if ( /*Something*/ ) // No!
>      {
>        i++;
>        j++;
>      }
>
> That is
>
>    if ( /*Something*/ ) // Yes!
>    {
>      i++;
>      j++;
>    }
>
> should be the only acceptable form. Once we use Astyle then I think this
> is|--style=ansi
>
> Further Astyle options
>
> ||--indent=tab=4 // indent using tabs, and each tab is 4 spaces|
> |--brackets=break //should be covered in --style=ansi|produces the effect
> above
>
> |--indent-classes
> ||--indent-switches
> ||--indent-namespaces
> ||--indent-labels
> ||--indent-preprocessor
> ||--max-instatement-indent=40
> ||--pad=paren
>
>
> I'm not sure if I've missed anything important. We do need a config file
> for our use, so we only need to call astyle on the file itself. I had
> astyle as a tool in wxdev once, so it is certainly possible to use
> within the ide.
>

Agreed. I don't have any problems with these guidelines. The major thing is
to have an Astyle config file in SVN with these settings so that a developer
just has to remember to "astyle.exe -f wxdevide.config *.*" before
committing changes to SVN.


>
> Could I also suggest that developers keep two verions of the code on
> their systems? One which is a local copy of the svn head, and the second
> which is the actual work in progress copy. All changes should be
> transferred from the working copy to the svnhead copy before updating
> svn. This way we should be able to prevent updates to form files when
> all that has changed is the position of a component (unless that
> position/size change is warranted). We all know that to have the code
> generated we need to change something, and the easiest is to move a
> component, but that change doesn't have to be returned to svn.
>

I see your point here, but it's a little difficult logistically to do this.
I think what I might try is to keep two SVN directories, one called "MyCopy"
and one called "SVN_HEAD". Both will be linked to SVN HEAD, but (hopefully)
if I try to commit changes from MyCopy I'll catch the mistake beforehand. (I
wonder if there's a way to make Tortoise ignore my changes in the MyCopy
directory and just look for updates in SVN?) Otherwise, I can easily see the
MyCopy directory become out of sinc with other developers commits to SVN.


>
> Also (and unfortunately we don't seem to be able to do this currently)
> we need to have the designer place dialogs in a subdirectory. So for
> example the base directory should have all necessary files and the main
> form files, but that each dialog thereafter should be placed in its own
> folder. Thus each folder would contain three files (not yet decided
> about the xrc files) the .cpp/.h/.wxform files. Unfortunately I don't
> seem to be able to do this at the moment, but would like to see it
> happening.
>

You mean for both our source code and for the way the IDE behaves? So, for
example, the About dialog box in our source code will be place in a
subdirectory called "AboutFrm"? I suppose that makes sense (although it will
create a massive number of subdirectories).

One thing I thought of in regards to dialogs: We should build the filename
for the .h, .cpp, and .wxform into the class definition for the dialog. I
think right now we are always assuming that all 3 files will have the same
prototype name (e.g. AboutFrm.cpp, AboutFrm.h, AboutFrm.wxform). So it's
hardcoded that a .wxform file called AboutFrm.wxform will always try to
modify code in files called AboutFrm.cpp and AboutFrm.h. It would be nice to
be able to generalize this in case a user every wanted to rename the files.

-Tony

-Tony