[OpenLayers-Dev] jslint results

[Erik Uzureau]

Dear Paul,

I approve of each and every one of the numbered resolutions you
suggest herebelow. They will all contribute to a more standardized,
consistent, readable codebase.

You have my +1
Erik

On 10/16/07, Paul Spencer <pspencer at dmsolutions.ca> wrote:
> Thanks Erik.  Before I go ahead and make a bunch of changes, though,
> I'd like some feedback on how pedantic we should be about certain
> coding practices.  I'd like feedback from the core devs on the
> following things:
>
> 1) use of semi-colons
>
> Should we care about certain edge cases, such as:
>
> var f = function(){return true};
>
> will say that you need a semi-colon after true (inside the block
> scope of the function)
>
> 2) use of curly braces around block scope
>
> Should we care about one line cases and implied scope, such as:
>
> if (this.singleLayer) return;
>
> for (var i=0; i<this.grid.length; i++)
>      if (this.grid[i].length) {
>      }
>
> 3) unreachable code
>
> function foo() {
>      return true;
>      var test = 1;
> }
>
> 4) missing break statements, missing break in last case of switch
>
> 5) leading or trailing decimal points
>
> .000
>
> 000.
>
> 6) nested comments
>
> /****************
> /* comment
> /****************/
>
> There are quite a few more options that can be used too, but are
> disabled by default because they have more of an impact on coding style.
>
> I personally like the ones above because they are situations that can
> lead to erroneous code in a multi-developer environment.
>
> I am also not advocating that we fix every warning that comes out of
> the tool, but rather that it can help us focus on specific potential
> problem areas - i.e. not using break statements in a switch is a
> reasonable technique in some instances.
>
> Please give me feedback on whether you want me to vet the code for
> the above issues or not.  I will make a single commit with all the
> changes on the current trunk once it is decided what we should or
> shouldn't include.  Thereafter, I will check trunk occasionally,
> especially before we cut a release, and do touch ups as required.
>
> Cheers
>
> Paul
>
> >
> > As a core committer, you should feel free to make these changes as you
> > see fit. OpenLayers has a (somewhat unstated) policy that
> > non-functional patches need not go through the standard
> > ticket/approval system.
> >
> > ...which means that if you want to replace a missing semicolon or tab
> > out a line or add a comment or something like that, you should just go
> > ahead and do it. As long as it doesn't change the functioning of the
> > code.
> >
> > Erik
> >
> > ps. thanks so much for taking the time to run this analysis. Looks
> > like our code has not a few little oversights!
> >
> >
> >> The regular expression one I am not so sure about.  Anyone know
> >> anything about javascript syntax in this particular case?
> >>
> >> Cheers
> >>
> >> Paul
> >>
> >>
> >> +-----------------------------------------------------------------+
> >> |Paul Spencer                          pspencer at dmsolutions.ca    |
> >> +-----------------------------------------------------------------+
> >> |Chief Technology Officer                                         |
> >> |DM Solutions Group Inc                http://www.dmsolutions.ca/ |
> >> +-----------------------------------------------------------------+
> >>
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> Dev mailing list
> >> Dev at openlayers.org
> >> http://openlayers.org/mailman/listinfo/dev
> >>
>
> +-----------------------------------------------------------------+
> |Paul Spencer                          pspencer at dmsolutions.ca    |
> +-----------------------------------------------------------------+
> |Chief Technology Officer                                         |
> |DM Solutions Group Inc                http://www.dmsolutions.ca/ |
> +-----------------------------------------------------------------+
>
>
>
>
>
>