Return to Answer

• Formatting  : the splitting of conditionals into separate lines is overdone, function rig_props is the worst case of overdoing it. You can find a fairly authoritative style guide here : http://javascript.crockford.com/code.html

• Arrow head coding : http://www.codinghorror.com/blog/2006/01/flattening-arrow-code.html If code has the following, then it was done wrong:

                                        }
                                     );
                                }
                            );
                        }
                    }
                    return obj;
                }
            }
        );
    }
    return obj;
}

• Naming  : please use camelCasing and meaningful names, the code is too hard to follow (  slc, t  , nl  ,un  , _tm .. ), I understand you are used to it, but if you ever want other people to understand/maintain this, then you need to fix this.

• Naming  : underscores used to indicate private properties/functions, they seem bad form for parameters (  _host_  , _aproto  ) , see also the Crockford style guide.

• It defines .each(), you should really look into using ForEach() instead, also look into reverse() for flgIterBw. forEach can be many times faster than a js loop.

• Functions like _aproto.keep should have at least a one-liner comment as to what it does

• Come to think of it, the code that enhances the array prototype should really be an object on it's own, and not stashed away in Timer as the code is re-usable. This would follow the principle of Separation of Concerns.

• All in all, the code is hard to maintain, not evenly commented and it does not seem to consider the advances made in js 1.6 ( ForEach, filter, etc.  ) but it still counts on indexOf()

• Finally, if the code were to be rewritten with the above in mind, it could get more meaningful code reviews because more reviewers could then grok it.

• Formatting: the splitting of conditionals into separate lines is overdone, function rig_props is the worst case of overdoing it. You can find a fairly authoritative style guide here.

• Arrow head coding. If code has the following, then it was done wrong:

                                          }
                                       );
                                  }
                              );
                          }
                      }
                      return obj;
                  }
              }
          );
      }
      return obj;
  }
  

• Naming: please use camelCasing and meaningful names. The code is too hard to follow (slc, t, nl,  un, _tm). I understand you are used to it, but if you ever want other people to understand/maintain this, then you need to fix this.

• Naming: underscores used to indicate private properties/functions. They seem bad form for parameters (_host_, _aproto). See also the Crockford style guide.

• It defines .each(), and you should really look into using ForEach() instead. Also, look into reverse() for flgIterBw. forEach can be many times faster than a JS loop.

• Functions like _aproto.keep should have at least a one-liner comment as to what it does.

• Come to think of it, the code that enhances the array prototype should really be an object on its own, and not stashed away in Timer as the code is re-usable. This would follow the principle of Separation of Concerns.

• All in all, the code is hard to maintain, not evenly commented and it does not seem to consider the advances made in JS 1.6 (ForEach, filter, etc.) but it still counts on indexOf().

• Finally, if the code were to be rewritten with the above in mind, it could get more meaningful code reviews because more reviewers could then grok it.

• Naming : please use camelCasing and meaningful names, the code is too hard to follow ( slc, t , nl ,un , _tm .. ), I understand you are used to it, but if you ever want other people to understand/maintain this, then you need to fix this.

• Naming : underscores used to indicate private properties/functions, they seem bad form for parameters ( _host_ , _aproto ) , see also the Crockford style guide.

• It defines .each(), you should really look into using ForEach() instead, also look into reverse() for flgIterBw. forEach can be many times faster than a js loop.

• Functions like _aproto.keep should have at least a one-liner comment as to what it does

• All in all, the code is hard to maintain, not evenly commented and it does not seem to consider the advances made in js 1.6 ( ForEach, filter, etc. ) but it still counts on indexOf()

• Finally, if the code were to be rewritten with the above in mind, it could get more meaningful code reviews because more reviewers could then grok it.

• Naming : please use camelCasing and meaningful names, the code is too hard to follow ( slc, t , nl ,un , _tm .. ), I understand you are used to it, but if you ever want other people to understand/maintain this, then you need to fix this.

• Naming : underscores used to indicate private properties/functions, they seem bad form for parameters ( _host_ , _aproto ) , see also the Crockford style guide.

• It defines .each(), you should really look into using ForEach() instead, also look into reverse() for flgIterBw. forEach can be many times faster than a js loop.

• Functions like _aproto.keep should have at least a one-liner comment as to what it does

• Come to think of it, the code that enhances the array prototype should really be an object on it's own, and not stashed away in Timer as the code is re-usable. This would follow the principle of Separation of Concerns.

• All in all, the code is hard to maintain, not evenly commented and it does not seem to consider the advances made in js 1.6 ( ForEach, filter, etc. ) but it still counts on indexOf()

• Finally, if the code were to be rewritten with the above in mind, it could get more meaningful code reviews because more reviewers could then grok it.

• Formatting : ( subjective ), the splitting of conditionals into separate lines is overdone, function rig_props is the worst case of overdoing it

• Arrow head coding : http://www.codinghorror.com/blog/2006/01/flattening-arrow-code.html If code has the following, then it was done wrong:

• Naming : please use camelCasing and meaningful names, the code is too hard to follow ( slc, t , nl ,un , _tm .. ), I understand you are used to it, but if you ever want other people to understand/maintain this, then you need to fix this.

• Naming : underscores used to indicate private properties/functions, they seem bad form for parameters ( _host_ , _aproto )

• It defines .each(), you should really look into using ForEach() instead, also look into reverse() for flgIterBw

• Functions like _aproto.keep should have at least a one-liner comment as to what it does

• All in all, the code is hard to maintain, not evenly commented and it does not seem to consider the advances made in js 1.6 ( ForEach, filter, etc. ) but it still counts on indexOf()

• Finally, if the code were to be rewritten with the above in mind, it could get more meaningful code reviews because more reviewers could then grok it.

• Formatting : the splitting of conditionals into separate lines is overdone, function rig_props is the worst case of overdoing it. You can find a fairly authoritative style guide here : http://javascript.crockford.com/code.html

• Arrow head coding : http://www.codinghorror.com/blog/2006/01/flattening-arrow-code.html If code has the following, then it was done wrong:

• Naming : please use camelCasing and meaningful names, the code is too hard to follow ( slc, t , nl ,un , _tm .. ), I understand you are used to it, but if you ever want other people to understand/maintain this, then you need to fix this.

• Naming : underscores used to indicate private properties/functions, they seem bad form for parameters ( _host_ , _aproto ) , see also the Crockford style guide.

• It defines .each(), you should really look into using ForEach() instead, also look into reverse() for flgIterBw. forEach can be many times faster than a js loop.

• Functions like _aproto.keep should have at least a one-liner comment as to what it does

• All in all, the code is hard to maintain, not evenly commented and it does not seem to consider the advances made in js 1.6 ( ForEach, filter, etc. ) but it still counts on indexOf()

• Finally, if the code were to be rewritten with the above in mind, it could get more meaningful code reviews because more reviewers could then grok it.