Javascript Best Practices Document v1.0

Discussion in 'Javascript' started by Matt Kruse, Oct 11, 2005.

  1. Matt Kruse

    Matt Kruse Guest

    http://www.JavascriptToolbox.com/bestpractices/

    I started writing this up as a guide for some people who were looking for
    general tips on how to do things the 'right way' with Javascript. Their code
    was littered with document.all and eval, for example, and I wanted to create
    a practical list of best practices that they could easily put to use.

    The above URL is version 1.0 (draft) that resulted. IMO, it is not a
    replacement for the FAQ, but a more practical guide for fixing some of the
    problems that commonly get pushed into web sites.

    Any comments?

    PS: Ignore the formatting. It's ugly, for now ;)

    PPS: I know that there are exceptions to many of the 'best practices' in
    very specific situations when approached by an experienced author, but the
    goal of this document is to help the average joe developer fix common
    problems and write more acceptable code.

    --
    Matt Kruse
    http://www.JavascriptToolbox.com
    http://www.AjaxToolbox.com
     
    Matt Kruse, Oct 11, 2005
    #1
    1. Advertising

  2. Matt Kruse a écrit :
    > http://www.JavascriptToolbox.com/bestpractices/
    >
    > I started writing this up as a guide for some people who were looking for
    > general tips on how to do things the 'right way' with Javascript.


    Good idea! I support such initiative.

    Their code
    > was littered with document.all and eval,


    You're most likely right. The top nr 1 problem with DHTML/javascript
    code on the web is still the recourse to document.all. Still today, in
    this very newsgroup, a lot of people are still promoting it in the name
    of supporting MSIE 4 ... which I think is just stupid. Less than 0.5% of
    internet/web users worldwide are still using MSIE 4 and the chances that
    some DHTML/javascript stuff can effectively work on MSIE 4 is very slim.
    So, I'd recommend to ditch document.all everywhere... including in this
    newsgroup.

    for example, and I wanted to create
    > a practical list of best practices that they could easily put to use.
    >
    > The above URL is version 1.0 (draft) that resulted. IMO, it is not a
    > replacement for the FAQ, but a more practical guide for fixing some of the
    > problems that commonly get pushed into web sites.
    >
    > Any comments?
    >
    > PS: Ignore the formatting. It's ugly, for now ;)


    The formatting is ok for me.


    1- I think you should start with something as basic as explaining that
    document.all is bad, wrong, deprecated, obsolete, etc..

    2- The web standards way to reference a form input element is:

    document.forms.namedItem("formname").elements.namedItem("inputname")

    http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-1689064

    http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-21069976

    http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-76728479

    3- "All forms should have a name attribute. Referencing forms using
    indexes, such as document.forms[0] is bad practice."
    name attribute for form was dropped in XHTML specification. So you may
    want to add such nuance/relativity in there.

    4- <form name="myform">
    <input type="text" name="val1" value="1">
    <input type="text" name="val2" value="2">
    </form>
    will trigger a validation markup error with a DTD strict.

    5- "To fix this problem, Javascript needs a hint to tell it to treat the
    values as numbers, rather than strings. Subtracting 0 from the value
    will force javascript to consider the value as a number, and then using
    the + operator on a number will perform addition, rather than
    concatenation."
    I think you may be in fact teaching a wrong trick. What's wrong with
    offering to use parseInt(strValParam, indexParam) to achieve exactly
    what you want to achieve... which is converting a string into an integer
    or to use parseFloat(strValParam).

    6- "This is why 'return false;' is often included at the end of the code
    within an onClick handler."
    I would remove that sentence. The sentence does not perfectly make
    sense. Also, we have no idea what the doSomething() function does exactly...

    7- "Often, links will just contain href="#" for the sake of simplicity,
    when you know for sure that your users will have javascript enabled."
    This is what a lot of people denounce also as bad coding practices. A
    link should be a link. A rose should be a rose. And href="#" is just bad
    practice IMO.
    Addendum: I see that you later discourage that practice.

    8- IMO, you do not sufficiently explain why href="javascript:..." is
    bad. May I recommend some of the reasons listed here:
    http://developer.mozilla.org/en/doc...D.22javascript:window.open.28....29.22_....3E

    9- In your "Detecting Browser Versions" section, you may want to give
    more references:
    - Browser identification approach (aka "browser sniffing"): not best,
    not reliable approach
    http://www.mozilla.org/docs/web-developer/upgrade_2.html#BrowserIdent
    - Using Object/Feature detection approach: best and overall most reliable
    http://www.mozilla.org/docs/web-developer/upgrade_2.html#ObjectFeatDetect
    - Browser detection - No; Object detection - Yes by Peter-Paul Koch
    http://www.quirksmode.org/js/support.html
    - Browser Detection and Cross Browser Support (in particular, sections 5
    and 6):
    http://developer.mozilla.org/en/docs/Browser_Detection_and_Cross_Browser_Support

    10-
    "The rules for using document.all are
    2. Only fall back to using document.all as a last resort
    3. Only use it if you need IE 5.0 support or earlier "
    but IE 5.0 supports getElementById. The only possible reason to use
    document.all is if you absolutely need to code for IE 4.x. And why would
    you want to do some DHTML which would (could possibly) work in IE 4.x?
    I don't see a reason for using document.all anymore.

    Regards,

    Gérard
    --
    remove blah to email me
     
    Gérard Talbot, Oct 11, 2005
    #2
    1. Advertising

  3. Matt Kruse

    RobG Guest

    Matt Kruse wrote:
    > http://www.JavascriptToolbox.com/bestpractices/
    >
    > I started writing this up as a guide for some people who were looking for
    > general tips on how to do things the 'right way' with Javascript.

    [...]

    Have you thought of putting it up as a wiki? That way contributors
    build your 'best of' site for you - it might get quite extensive though!

    It would be good to have some 'best practice' examples or stubs for
    various things - form validation, dynamic HTML stuff getting xml files,
    calendars and date pickers, etc. - rather than a plethora of sites with
    half-baked solutions.

    [...]

    --
    Rob
     
    RobG, Oct 11, 2005
    #3
  4. On 11/10/2005 07:02, Gérard Talbot wrote:

    [snip]

    > 1- I think you should start with something as basic as explaining that
    > document.all is bad, wrong, deprecated, obsolete, etc..


    But the all collection is neither bad nor wrong. It can be argued that
    it is largely redundant, but even in IE5.x is has a useful purpose
    (though not IE6).

    > 2- The web standards way to reference a form input element is:
    >
    > document.forms.namedItem("formname").elements.namedItem("inputname")


    What Matt wrote is just as 'compliant'. Read the ECMAScript bindings. It
    also benefits from better support (so it is better in itself).

    > 3- "All forms should have a name attribute. Referencing forms using
    > indexes, such as document.forms[0] is bad practice."
    > name attribute for form was dropped in XHTML specification.


    So? What's that got to do with anything?

    If NN4 (and the like) aren't a consideration (and they needn't be for
    client-side form validation), then use an id attribute, or pass
    references directly and omit an identifier entirely. However, if a name
    attribute is necessary, then use it.

    > 4- <form name="myform">
    > <input type="text" name="val1" value="1">
    > <input type="text" name="val2" value="2">
    > </form>
    > will trigger a validation markup error with a DTD strict.


    If you're writing to an XHTML Strict DTD, but that is arguably worse
    than reasonable defiance of the DTD.

    > 5- "To fix this problem, Javascript needs a hint to tell it to treat the
    > values as numbers, rather than strings. Subtracting 0 from the value
    > will force javascript to consider the value as a number, and then using
    > the + operator on a number will perform addition, rather than
    > concatenation."


    I would recommend the unary plus (+) operator instead.

    > I think you may be in fact teaching a wrong trick. What's wrong with
    > offering to use parseInt(strValParam, indexParam) to achieve exactly
    > what you want to achieve...


    It's overkill in most cases. The value should have been validated
    already, so all that's necessary is to convert the value which the unary
    plus operator does very well.

    The parseInt function can be very useful when using it to simultaneously
    strip non-numeric trailing characters and convert, such as with CSS
    length values.

    > 6- "This is why 'return false;' is often included at the end of the code
    > within an onClick handler."
    > I would remove that sentence. The sentence does not perfectly make
    > sense.


    It makes perfect sense when taken in context.

    > Also, we have no idea what the doSomething() function does exactly...


    You do know that it's just an example, don't you. :p

    > 7- "Often, links will just contain href="#" for the sake of simplicity,
    > when you know for sure that your users will have javascript enabled."
    > This is what a lot of people denounce also as bad coding practices.


    It's bad practice when that's used outside the scope of a script.
    However, if a script generates such a link, then it's not an issue. I
    believe that's what Matt was aiming at (notice, 'know for sure'), but
    perhaps it should be emphasised as the caveat might not be noticed.

    [snip]

    I haven't really read the document yet. I'll get around to it at some
    point... :)

    Mike

    --
    Michael Winter
    Prefix subject with [News] before replying by e-mail.
     
    Michael Winter, Oct 11, 2005
    #4
  5. JRS: In article <>, dated Tue, 11 Oct 2005
    02:02:23, seen in news:comp.lang.javascript, Gérard Talbot
    <> posted :
    >Matt Kruse a écrit :
    >> http://www.JavascriptToolbox.com/bestpractices/
    >>
    >> I started writing this up as a guide for some people who were looking for
    >> general tips on how to do things the 'right way' with Javascript.


    It will no doubt encourage a bloated programming style.


    >5- "To fix this problem, Javascript needs a hint to tell it to treat the
    >values as numbers, rather than strings. Subtracting 0 from the value
    >will force javascript to consider the value as a number, and then using
    >the + operator on a number will perform addition, rather than
    >concatenation."
    >I think you may be in fact teaching a wrong trick. What's wrong with
    >offering to use parseInt(strValParam, indexParam) to achieve exactly
    >what you want to achieve... which is converting a string into an integer
    >or to use parseFloat(strValParam).


    Does unary + not work in the circumstances?

    Note that if the actual parameter is a number already, unary + is
    essentially a no-op, whereas parseInt will cause a conversion to String
    (perhaps 1e+21) and a conversion of that to integer Number, with results
    maybe not as intended.

    X = 987654321987654321987654321
    Z = parseInt(X) // Z = 9

    --
    © John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4 ©
    <URL:http://www.jibbering.com/faq/> JL/RC: FAQ of news:comp.lang.javascript
    <URL:http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
    <URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.
     
    Dr John Stockton, Oct 11, 2005
    #5
  6. Matt Kruse

    Matt Kruse Guest

    Matt Kruse, Oct 12, 2005
    #6
  7. Matt Kruse

    Randy Webb Guest

    Matt Kruse said the following on 10/10/2005 11:06 PM:

    > http://www.JavascriptToolbox.com/bestpractices/
    >
    > I started writing this up as a guide for some people who were looking for
    > general tips on how to do things the 'right way' with Javascript. Their code
    > was littered with document.all and eval, for example, and I wanted to create
    > a practical list of best practices that they could easily put to use.
    >
    > The above URL is version 1.0 (draft) that resulted. IMO, it is not a
    > replacement for the FAQ, but a more practical guide for fixing some of the
    > problems that commonly get pushed into web sites.
    >
    > Any comments?


    <quote>
    Otherwise, it's always a good idea to put a local fall-back page that
    will be loaded for users without it disabled
    </quote>

    "for users with it disabled"

    The "What not to do" section on anchors should have a note - or maybe a
    seperate page - that explains why you shouldn't do those things.
    Including, but not limited, to the negative impacts they can have.

    document.all in IE

    <quote>
    Only use it if you need IE 5.0 support or earlier
    </quote>

    IE5.0, IIRC, supports gEBI so it should be priort to 5.0

    Also, somewhere in there, some type of paragraph or so on innerHTML and
    some of it's inherent strength's and weaknesses.

    The only major problem with the whole page is the last few lines about
    using Libraries which I totally disagree with. A newbe shouldn't be
    using tools that they don't understand and the whole page seems to be
    geared to some of the newbe mistakes that we were all guilty of
    committing at times (and I still do it myself occassionaly).

    Libraries are a personal choice and to me people should understand
    enough about the language to know when to use a Library not just how to
    use it. If all a person ever learns is that if they do this:

    DynWrite('someDiv',someHTML);

    That the page changes then they never learn and understand the inherent
    problems with DynWrite itself (which it does have) and that function
    comes straight from the FAQ itself for this group.

    Sidenote: The major problem with innerHTML is when the string being
    assigned is plain text. innerHTML has been proven, repeatedly, to be
    considerably slower that DOM methods or even the IE proprietary
    innerText property.





    --
    Randy
    comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
    Answer:It destroys the order of the conversation
    Question: Why?
    Answer: Top-Posting.
    Question: Whats the most annoying thing on Usenet?
     
    Randy Webb, Oct 12, 2005
    #7
  8. Matt Kruse

    Randy Webb Guest

    Dr John Stockton said the following on 10/11/2005 4:09 PM:

    > JRS: In article <>, dated Tue, 11 Oct 2005
    > 02:02:23, seen in news:comp.lang.javascript, Gérard Talbot
    > <> posted :
    >
    >>Matt Kruse a écrit :
    >>
    >>>http://www.JavascriptToolbox.com/bestpractices/
    >>>
    >>>I started writing this up as a guide for some people who were looking for
    >>>general tips on how to do things the 'right way' with Javascript.

    >
    >
    > It will no doubt encourage a bloated programming style.


    Before babbling nonsense like that you should, at minimum, at least read
    and be familiar with what you are babbling about.

    But, where is *your* guide to best practices?

    --
    Randy
    comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
     
    Randy Webb, Oct 12, 2005
    #8
  9. Michael Winter a écrit :
    > On 11/10/2005 07:02, Gérard Talbot wrote:
    >
    > [snip]
    >
    >> 1- I think you should start with something as basic as explaining that
    >> document.all is bad, wrong, deprecated, obsolete, etc..

    >
    >
    > But the all collection is neither bad nor wrong. It can be argued that
    > it is largely redundant, but even in IE5.x is has a useful purpose
    > (though not IE6).
    >


    Useful purpose for IE 5.x? Can you elaborate on this? what do you mean...

    >> 2- The web standards way to reference a form input element is:
    >>
    >> document.forms.namedItem("formname").elements.namedItem("inputname")

    >
    >
    > What Matt wrote is just as 'compliant'. Read the ECMAScript bindings. It
    > also benefits from better support (so it is better in itself).
    >


    Better support? Yes, it's possible. I just mentioned a purely web
    standards (DOM 2 HTML) way in there. That's all.

    >> 3- "All forms should have a name attribute. Referencing forms using
    >> indexes, such as document.forms[0] is bad practice."
    >> name attribute for form was dropped in XHTML specification.

    >
    >
    > So? What's that got to do with anything?
    >


    What I was suggesting here is that one can not declare, just like that,
    that document.forms[0] is a bad practice when it is a DOM 2 HTML valid
    practice in XHTML
    and when what you formally recommend implies an invalid (markup code)
    practice in XHTML.

    Just compare the following 2 quotes/statements:

    "All forms should have a name attribute." Matt K.

    "HTML 4 defined the name attribute for the elements a, applet, form,
    frame, iframe, img, and map. (...) in XHTML 1.0, the name attribute of
    these elements is formally deprecated, and will be removed in a
    subsequent version of XHTML."
    http://www.w3.org/TR/2002/REC-xhtml1-20020801/#h-4.10

    > If NN4 (and the like) aren't a consideration (and they needn't be for
    > client-side form validation), then use an id attribute, or pass
    > references directly and omit an identifier entirely. However, if a name
    > attribute is necessary, then use it.
    >


    Yes, id attribute is another way. name attribute can not be the only way
    since it implies invalid markup code in XHTML.

    >> 4- <form name="myform">
    >> <input type="text" name="val1" value="1">
    >> <input type="text" name="val2" value="2">
    >> </form>
    >> will trigger a validation markup error with a DTD strict.

    >
    >
    > If you're writing to an XHTML Strict DTD, but that is arguably worse
    > than reasonable defiance of the DTD.
    >


    Well, what if I am writing in HTML 4.01 strict then? The above code will
    be reported as invalid markup by validators. I am repeating myself here.

    >> 5- "To fix this problem, Javascript needs a hint to tell it to treat
    >> the values as numbers, rather than strings. Subtracting 0 from the
    >> value will force javascript to consider the value as a number, and
    >> then using the + operator on a number will perform addition, rather
    >> than concatenation."

    >
    >
    > I would recommend the unary plus (+) operator instead.
    >
    >> I think you may be in fact teaching a wrong trick. What's wrong with
    >> offering to use parseInt(strValParam, indexParam) to achieve exactly
    >> what you want to achieve...

    >
    >
    > It's overkill in most cases. The value should have been validated
    > already, so all that's necessary is to convert the value which the unary
    > plus operator does very well.
    >


    I don't agree with you. parseInt function original purpose (specific
    purpose, defined task) is to parse a string and convert it into
    integers. Isn't it what Matt Kruse' code wanted to specifically achieve
    to begin with?
    + is an overloaded operator; it's not even a function.


    > The parseInt function can be very useful when using it to simultaneously
    > strip non-numeric trailing characters and convert, such as with CSS
    > length values.
    >
    >> 6- "This is why 'return false;' is often included at the end of the
    >> code within an onClick handler."
    >> I would remove that sentence. The sentence does not perfectly make sense.

    >
    >
    > It makes perfect sense when taken in context.
    >


    I disagree. It does not make sense within the context, as written
    in the document. We have no idea what doSomething() function actually does.

    >> Also, we have no idea what the doSomething() function does exactly...

    >
    >
    > You do know that it's just an example, don't you. :p
    >


    The provided code is an abstract example. It's not a defined example.
    It's not a concrete example, serving a specified purpose.

    This page:
    https://bugzilla.mozilla.org/attachment.cgi?id=111215
    (from bug 44449 at bugzilla)
    is a concrete example showing and testing a precise issue.

    This example:
    http://developer.mozilla.org/en/docs/DOM:window.open#Best_practices
    is a whole concrete example showing, demontrating, accomplishing a
    precise, concrete goal, task.

    There is no general rule for returning false in a script, in an onclick
    event attribute. It all depends on what a script actually does within a
    real-live webapge context. The Matt K. document suggests otherwise.


    >> 7- "Often, links will just contain href="#" for the sake of
    >> simplicity, when you know for sure that your users will have
    >> javascript enabled."
    >> This is what a lot of people denounce also as bad coding practices.

    >
    >
    > It's bad practice when that's used outside the scope of a script.


    I'm sorry: I disagree. It's *_always_* a bad practice in my opinion.
    href="#" should never be used anywhere.
    Matt K. discourage href="#" but not to the level I would.

    > However, if a script generates such a link, then it's not an issue.


    .... then a real button describing the purpose of the script should be
    used, not a link. A rose is a rose is a rose. A link should be a real
    link should be a real link. And a script modifying a DOM tree or a
    document structure should be described as such.

    "Links that don't behave as expected undermine users' understanding of
    their own system. A link should be a simple hypertext reference that
    replaces the current page with new content"
    J. Nielsen


    > [snip]
    >
    > I haven't really read the document yet.


    Well, then, maybe it would be a good idea to do so.

    > I'll get around to it at some
    > point... :)
    >
    > Mike


    Gérard
    --
    remove blah to email me
     
    Gérard Talbot, Oct 12, 2005
    #9
  10. On 12/10/2005 04:56, Gérard Talbot wrote:

    [The all collection]

    > Useful purpose for IE 5.x? Can you elaborate on this? what do you
    > mean...


    The getElementsByTagName method is not implemented properly in IE5.x.
    Passing an asterisk (*) will always return an empty collection, rather
    than one that contains all descendants of the node. The most reasonable
    solution is to detect this failure and use the all collection in place.

    [Using the namedItem methods of collections, rather than square brackets]

    > Better support? Yes, it's possible.


    It's guaranteed.

    > I just mentioned a purely web standards (DOM 2 HTML) way in there.
    > That's all.


    Using square brackets /is/ a 'purely web standards [...] way'.

    [The name attribute in XHTML]

    > What I was suggesting here is that one can not declare, just like that,
    > that document.forms[0] is a bad practice when it is a DOM 2 HTML valid
    > practice in XHTML


    Unless one is iterating through a collection, using numeric indices is
    not a recommended practice as changes to markup mandate a change to the
    script, whereas using some form of identifier (or direct reference,
    which is what I really recommend) does not.

    > and when what you formally recommend implies an invalid (markup code)
    > practice in XHTML.


    As you were told in ciwah, validation is not a goal in itself. There can
    be justified reasons for writing invalid markup[1], and using the name
    attribute is not going to break a browser if you truly understand how
    browsers will be treating the markup. After all, they won't be parsing
    the document as XHTML anyway, so use that notation is, at most,
    superficial use of an XML-based language. You would be better off
    abandoning XHTML as an output format for the time being (for several
    years, at least) and using HTML. That is a better use of your time than
    worrying about a single attribute.

    [snip]

    >>> 4- <form name="myform">
    >>> <input type="text" name="val1" value="1">
    >>> <input type="text" name="val2" value="2">
    >>> </form>


    [snip]

    > Well, what if I am writing in HTML 4.01 strict then? The above code
    > will be reported as invalid markup by validators.


    For a different reason, yes, which has nothing to do with what we've
    just been discussing.

    There is no reason to omit the action attribute in actual markup, but
    again this is an example to illustrate an entirely unrelated concept;
    potential conflicts between concatenation and addition.

    [snip]

    >> [The parseInt function is] overkill in most cases. The value should
    >> have been validated already, so all that's necessary is to convert
    >> the value which the unary plus operator does very well.

    >
    > I don't agree with you. parseInt function original purpose (specific
    > purpose, defined task) is to parse a string and convert it into
    > integers.


    If the string has been validated as a number, which it should have been,
    then the only operation that is needed is conversion. The sole purpose
    of the unary plus operator is to convert its operand to a number. The
    parseInt function, on the other hand, parses only to an integer -
    totally different and often not as useful.

    > Isn't it what Matt Kruse' code wanted to specifically achieve
    > to begin with?


    No. Matt describes string to number conversion, not string to integer.

    > + is an overloaded operator; it's not even a function.


    The addition operator and the plus (+) symbol itself is overloaded. The
    unary plus operator is not. That the latter isn't a function is utterly
    irrelevant.

    [snip]

    >>> 6- "This is why 'return false;' is often included at the end of the
    >>> code within an onClick handler."


    [snip]

    > I disagree. It does not make sense within the context, as written
    > in the document. We have no idea what doSomething() function actually does.


    It doesn't matter what that function does. Matt is demonstrating event
    cancellation (specifically, cancelling link navigation). Anything could
    be placed before the return statement, including a comment like

    /* Some code here */

    [snip]

    > There is no general rule for returning false in a script, in an onclick
    > event attribute.


    No, there isn't, but Matt isn't defining a general rule. The heading of
    the section is "Using onClick in <A> tags", and returning false in that
    context is well-defined.

    >>> 7- "Often, links will just contain href="#" for the sake of
    >>> simplicity, when you know for sure that your users will have
    >>> javascript enabled."


    [snip]

    > I'm sorry: I disagree. It's *_always_* a bad practice in my opinion.


    In markup, I agree with you absolutely, and I wouldn't use it in a
    script, either; I wouldn't use a link that's not a link.

    The reason why a "#" href attribute value is frowned upon is because is
    doesn't do anything. If the script cannot act, for whatever reason, the
    user is left with a link that doesn't do anything. This is contrary to
    what a link implies. If the script generates the link, and the link's
    scripted action can be /guaranteed/ to work, then the usability issue
    doesn't imply. The argument now is just whether it's appropriate to use
    a link at all.

    >> I haven't really read the document yet.

    >
    > Well, then, maybe it would be a good idea to do so.


    I had neither the time, nor the inclination last night to read
    through that document and possibly draft my own response. However, I
    thought your post needed commenting upon as I felt parts of it were
    suggesting changes that were misguided.

    Mike


    [1] I don't believe that structurally invalid markup is acceptable,
    but certain minor violations /can/ be justified. However, I do
    advocate that authors should learn and practice writing valid
    documents whenever possible.

    --
    Michael Winter
    Prefix subject with [News] before replying by e-mail.
     
    Michael Winter, Oct 12, 2005
    #10
  11. Matt Kruse

    Matt Kruse Guest

    Gérard Talbot wrote:
    > What I was suggesting here is that one can not declare, just like
    > that, that document.forms[0] is a bad practice when it is a DOM 2
    > HTML valid practice in XHTML
    > and when what you formally recommend implies an invalid (markup code)
    > practice in XHTML.


    XHTML sucks :)
    In reality, most people don't need to consider it, and anyone being forced
    to use XHTML surely is not looking for the basic level of suggestions that I
    included in my document.

    If you include every exception and side-notes about every other way of doing
    things, the document becomes huge and unreadable to most average users who
    just want a few hints on how to do things better.

    > Well, what if I am writing in HTML 4.01 strict then? The above code
    > will be reported as invalid markup by validators. I am repeating
    > myself here.


    It's an abbreviated example to show the point. It is not intended to be
    full, correct markup.

    > I'm sorry: I disagree. It's *_always_* a bad practice in my opinion.
    > href="#" should never be used anywhere.


    Well, then we disagree. I use href="#" all the time within web apps that
    require javascript. Especially when there are hundreds of links on a page,
    having each one contain a useless href is pointless, when the user is known
    to have javascript enabled. You're welcome to write and publish your own
    Best Practices document :)

    --
    Matt Kruse
    http://www.JavascriptToolbox.com
    http://www.AjaxToolbox.com
     
    Matt Kruse, Oct 12, 2005
    #11
  12. Matt Kruse

    Matt Kruse Guest

    Randy Webb wrote:
    > [snip]


    I've corrected a few of the things you've suggested. Thanks!

    > The only major problem with the whole page is the last few lines about
    > using Libraries which I totally disagree with. A newbe shouldn't be
    > using tools that they don't understand...


    The use of "libraries" will always be a debate among regulars of this group.

    My take has always been that it would be fantastic if everyone could
    understand javascript well enough to write their own widgets when they need
    them, or at least pick the best ones of those available.

    But _reality_ is something different. Most people don't want to learn a lot
    about javascript, or don't have time to implement a generalized
    cross-browser solution to some problems. I've received hundreds if not
    thousands of thank-you's from people saying things like "I needed to add a
    calendar popup in my project at work, and I had almost no time left. I
    implemented yours in literally 10 minutes and it works perfectly. Thank you
    so much!" I think libraries are important for situations like that, and also
    for situations where users know what they want but don't have the expertise
    to implement it. A person need not be an expert in everything in order to
    use the tools available.

    A javascript "library" is simply a packaged solution with an
    easily-understood interface. We all use those all the time. I bet you aren't
    telneting to your news server and issuing NNTP commands by hand, are you?
    You're using a higher-level tool so that you don't _have_ to understand the
    NNTP protocol. If you have to understand the inner-workings of every tool
    you use daily, you could never accomplish anything. Using libraries and
    higher-level tools is essential to being more creative and building bigger
    and better solutions.

    If a javascript library is implemented well enough, with a good interface,
    with not a lot of extra code, then I don't see any reason not to use it or
    recommend that others use it. I know others disagree, and that's fine. But I
    won't be convinced any time soon. Especially when I get thousands of
    visitors to my libraries each day, many thank-you emails each month, and
    donations from companies and individuals whose projects and timelines were
    saved because they found a packaged solution to a common problem that they
    could implement in minutes rather than hours or days. And _especially_ when
    many of the "anti-library" folks don't offer feasible alternatives for
    people faced with challenges that are easily solved by using a decent
    library :)

    --
    Matt Kruse
    http://www.JavascriptToolbox.com
    http://www.AjaxToolbox.com
     
    Matt Kruse, Oct 12, 2005
    #12
  13. On 11/10/2005 04:06, Matt Kruse wrote:

    > http://www.JavascriptToolbox.com/bestpractices/


    "Square Bracket Notation"

    You might want to note the different restrictions that both forms have.
    That is, the token that forms each part of the dot notation property
    accessor must conform to the Identifier production, whereas property
    names used with square brackets have no such restrictions. However, the
    expression within the brackets will /always/ be type-converted to a string.

    This might also be a good time to follow on and dispel the idea about
    hash 'arrays'.

    I don't know about always using square bracket notation.


    "Referencing Forms And Form Elements"

    Further to Gérard's complaint, it might be better to refer abstractly to
    form identifiers (as both the name and id attributes are supposed to be
    unique identifiers), unless the author is referring to the form through
    an event listener in which case no identifier is needed.


    "Problems With Concatenation"

    +theform.elements["val1"].value + +theform.elements["val2"].value

    I think it's better to use parentheses around the unary expression,
    especially with the right-hand operand above.

    It might be better to reference the elements collection directly, rather
    than the form (at least when you aren't dealing with the form itself).

    var controls = document.forms.myForm.elements,
    total = +controls.val1.value + (+controls.val2.value);


    "Getting And Setting Form Values"

    "[Using unified functions for] forms with only 1 radio button
    in a group [...]"

    A singular radio button should never exist. If the document is generated
    server-side (surely the only reason this situation could occur), that
    form control should be removed and the served script altered to only
    deal with a single control.

    Mike

    --
    Michael Winter
    Prefix subject with [News] before replying by e-mail.
     
    Michael Winter, Oct 12, 2005
    #13
  14. JRS: In article <>, dated Tue, 11 Oct
    2005 23:15:34, seen in news:comp.lang.javascript, Randy Webb
    <> posted :
    >
    >Sidenote: The major problem with innerHTML is when the string being
    >assigned is plain text. innerHTML has been proven, repeatedly, to be
    >considerably slower that DOM methods or even the IE proprietary
    >innerText property.


    Which in the majority of cases is totally unimportant. Since the aim is
    to change the information presented to the mind of the user, the time
    taken is usually significant only if it exceeds about 200 ms.

    My Holidays page computes and writes a whole annual holidays table
    (about 1.5 windows high) covering 6 years, using DynWrite, in a
    perceptible fraction of a second, on a 300 MHz PII. That's good enough.

    --
    © John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4 ©
    <URL:http://www.jibbering.com/faq/> JL/RC: FAQ of news:comp.lang.javascript
    <URL:http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
    <URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.
     
    Dr John Stockton, Oct 12, 2005
    #14
  15. Michael Winter a écrit :
    > On 12/10/2005 04:56, Gérard Talbot wrote:
    >
    > [The all collection]
    >
    >> Useful purpose for IE 5.x? Can you elaborate on this? what do you
    >> mean...

    >
    >
    > The getElementsByTagName method is not implemented properly in IE5.x.
    > Passing an asterisk (*) will always return an empty collection,


    I didn't know that.

    rather
    > than one that contains all descendants of the node. The most reasonable
    > solution is to detect this failure and use the all collection in place.
    >
    >
    > Using square brackets /is/ a 'purely web standards [...] way'.
    >
    > [The name attribute in XHTML]
    >
    >> What I was suggesting here is that one can not declare, just like that,
    >> that document.forms[0] is a bad practice when it is a DOM 2 HTML valid
    >> practice in XHTML

    >
    >
    > Unless one is iterating through a collection, using numeric indices is
    > not a recommended practice


    Matt K. explicitly states that numeric indices is a bad practice.
    "Referencing forms using indexes, such as document.forms[0] is bad
    practice."

    as changes to markup mandate a change to the
    > script, whereas using some form of identifier (or direct reference,
    > which is what I really recommend) does not.
    >
    >> and when what you formally recommend implies an invalid (markup code)
    >> practice in XHTML.

    >
    >
    > As you were told in ciwah, validation is not a goal in itself. There can
    > be justified reasons for writing invalid markup[1],


    I don't recall being told that.

    and using the name
    > attribute is not going to break a browser if you truly understand how
    > browsers will be treating the markup. After all, they won't be parsing
    > the document as XHTML anyway, so use that notation is, at most,
    > superficial use of an XML-based language. You would be better off
    > abandoning XHTML as an output format for the time being (for several
    > years, at least) and using HTML.


    A document about javascript best practices can not and should not rule
    out/exclude people who serve XHTML document as application/xhtml+xml.
    Otherwise, at the very least, the document should then state that it is
    intended for HTML based documents only.

    > That is a better use of your time than
    > worrying about a single attribute.



    Somehow the tone of your post has become personal. All my posts were
    referring to the draft document.

    I never used more than 2 forms in a single page. Most of the time, I
    only have 1. So what's the big deal with numeric indice?
    All I can read in the document is a simple directive in the document
    regarding numeric indice: no explanation as to why such directive and no
    recommended solution for XHTML-based documents.

    It wouldn't take a lot of words to compensate for these 2 issues...

    > [snip]
    >
    >>>> 4- <form name="myform">
    >>>> <input type="text" name="val1" value="1">
    >>>> <input type="text" name="val2" value="2">
    >>>> </form>

    >
    >
    > [snip]
    >
    >> Well, what if I am writing in HTML 4.01 strict then? The above code
    >> will be reported as invalid markup by validators.

    >
    >
    > For a different reason, yes, which has nothing to do with what we've
    > just been discussing.
    >


    When should someone bring this up then? When a "HTML Best Practices"
    document is released? Writing valid markup code should always be the norm.

    > There is no reason to omit the action attribute in actual markup, but
    > again this is an example to illustrate an entirely unrelated concept;
    > potential conflicts between concatenation and addition.


    This example is not just an isolated chunck of code in an ordinary
    webpage. Matt K. actually wants people to follow such example and other
    examples as well. So why not make it perfectly valid then?

    <form name="myform" action=""> <p> <input type="text" name="val...e a model. Gérard -- remove blah to email me
     
    Gérard Talbot, Oct 13, 2005
    #15
  16. Matt Kruse a écrit :
    > Gérard Talbot wrote:
    >
    >>What I was suggesting here is that one can not declare, just like
    >>that, that document.forms[0] is a bad practice when it is a DOM 2
    >>HTML valid practice in XHTML
    >>and when what you formally recommend implies an invalid (markup code)
    >>practice in XHTML.

    >
    >
    > XHTML sucks :)
    > In reality, most people don't need to consider it, and anyone being forced
    > to use XHTML surely is not looking for the basic level of suggestions that I
    > included in my document.
    >


    I think it would be fair to indicate to all readers of that page that
    your best practices are for HTML documents only, then.

    > If you include every exception and side-notes about every other way of doing
    > things, the document becomes huge and unreadable


    This is exaggerated.

    to most average users who
    > just want a few hints on how to do things better.
    >
    >
    >>Well, what if I am writing in HTML 4.01 strict then? The above code
    >>will be reported as invalid markup by validators. I am repeating
    >>myself here.

    >
    >
    > It's an abbreviated example to show the point. It is not intended to be
    > full, correct markup.
    >


    But people don't know that. And newbies can not and will not know that.
    The web is litterally full of webpages where examples were tried, were
    trusted, copied and pasted. Dynamicdrive.com and other javascript
    copy-N-paste are full of examples of dubious quality, poor coding
    practices and invalid markup code.

    It wouldn't take a lot more typing to correct this. Writing valid markup
    code shouldn't be a luxury in your document. Just consider what your
    document aspires to present: javascript best practices.

    >
    >>I'm sorry: I disagree. It's *_always_* a bad practice in my opinion.
    >>href="#" should never be used anywhere.

    >
    >
    > Well, then we disagree. I use href="#" all the time within web apps that
    > require javascript. Especially when there are hundreds of links on a page,
    > having each one contain a useless href is pointless, when the user is known
    > to have javascript enabled. You're welcome to write and publish your own
    > Best Practices document :)


    WCAG groups and J. Nielsen have already written on this whole issue.
    A script triggered by an onclick event handler in a link should not do a
    lot more than a plain vanilla link does otherwise you're not using a
    link for its intended purpose to begin with. In such case, you may be
    misusing the <a> element; a <button type="button"
    onclick="doSomething();"> would most likely be better markup usage,
    better semantic.

    You never gave an example of what doSomething() would be about, could
    do. So, the doSomething() example is not concrete, not demonstrating a
    possible good usage, etc. The doSomething() example is promoting a
    general use of canceling the return value.

    Gérard
    --
    remove blah to email me
     
    Gérard Talbot, Oct 13, 2005
    #16
  17. Matt Kruse wrote:
    > Randy Webb wrote:
    >> [snip]

    >
    > I've corrected a few of the things you've suggested. Thanks!
    >
    >> The only major problem with the whole page is the last few lines
    >> about using Libraries which I totally disagree with. A newbe
    >> shouldn't be using tools that they don't understand...

    >
    > The use of "libraries" will always be a debate among
    > regulars of this group.


    It isn't debated that much, the only people who seem to argue in favour
    of libraries are individuals who have libraries to promote. It seems
    that the vested interest and unwillingness to abandon the time already
    invested tends to encourage intransigence. When we have the debate the
    majority of expressed opinion has always been against the use of
    monolithic generalised libraries as an inappropriate concept in browser
    scripting.

    > My take has always been that it would be fantastic if
    > everyone could understand javascript well enough to
    > write their own widgets when they need them, or at least
    > pick the best ones of those available.
    >
    > But _reality_ is something different. Most people don't want
    > to learn a lot about javascript, or don't have time to
    > implement a generalized cross-browser solution to some problems.


    It is perverse to state this in the context of a request for comments on
    a document that asserts that its subject is "best Practices". Here you
    are arguing for expedience, but "best practice" most definitely is about
    ideals that should be aspired to and not short term expedience.

    > I've received hundreds if not thousands of thank-you's from
    > people saying things like "I needed to add a calendar popup
    > in my project at work, and I had almost no time left.
    > I implemented yours in literally 10 minutes and it works
    > perfectly. Thank you so much!"


    So a developer who either could not write the code they had undertaken
    to create, or could not accurately/effectively schedule their tasks gets
    to conceal their incompetence form their employer while reducing the
    viability (and so potential profitability) of whatever they have
    created? Yes, I can see widespread appeal for having that facility, it
    still doesn't make it a good idea.

    <snip>
    > ... , and donations from companies and individuals whose ...

    <snip>

    So your public support for libraries in general, and repeated promotion
    of your own libraries, is not without some financial motivation, and
    direct returns? I am reminded of Ira Baxter, who, in the face of
    widespread explanations of why javascript obfuscation is worthless,
    still maintains that it is a valuable practice, and then references
    people to the javascript obfuscateor that her employers sell.

    Anyway, to the "best practices" page; What I like to see when someone
    proposes something as a "best practice" is an explanation of why it
    might be considered a best Practice. Without that the assertion has only
    the weight of the individual who is making the assertion, and needs
    filtering through an appreciation of the personal prejudices (and vested
    interests of) the individual in question. With an explanation of why
    something could be regarded as a best practice it is possible to asses
    the proposal on the merits of the argument made for it. So, for example,
    when Gérard Talbot proposes:-

    document.forms.namedItem("formname").elements.namedItem("inputname")

    - as, in some sense, a "best practice" (or "correct practice") in
    accessing form controls, and supports that assertion with the
    justification:-

    "The web standards way to reference a form input element is:"

    - it is possible to assess the suggestion on the basis of its
    justification. And observe that the proposal is no more (and no less)
    "web standards" than the more ECMAScript-style and more cross-browser:-

    document.forms["formname"].elements["inputname"]

    That is, because there was a justification for the assertion it is
    possible to determine with certainty that it is bogus. Any practice
    proposed with a justification that cannot be as easily dismissed stands
    a much better chance of qualifying as a "best practice".

    Your page makes no justifications for the items it proposes as "best
    practice" and so is reduced to a sequence of personal assertions. And
    some of them are distinctly odd in context. For example, you propose
    that people use bracket notation, seemingly to the exclusion of dot
    notation (insane as that would be). I am not even sure that using
    bracket notation qualifies as a "practice" (in the sense of "best
    practice") at all. The best that can be said of bracket notation in the
    direction of "best practice" is that it should not be disregarded when
    using property accessors (particularly in favour of eval). But that is
    really just proposing that it is "best practice" to be familiar with the
    constructs, syntax, and behaviour of the language you are writing in
    (which is a bit too obvious an assertion to have been explicitly stated
    in any code authoring standards document that I have read to date).

    Without any justification for the proposed "best practices", and so
    their reduction to the status of personal assertions, it is interesting
    to note the number of links in the page to technical articles written by
    others. That seems almost a rhetorical ploy; the quality of the advice
    given on the page is bolstered by the quality of the material referenced
    from the page.

    On the whole your page is too superficial to justify its title, and the
    items covered are more reminiscent of a trivial FAQ than what it
    purports to be. Much that is widely held to be "best practice", in
    javascript or in programming in general is not mentioned at all. For
    example, the formal structuring and block indenting of development code
    (and the imposition of a single style of such formatting within
    organisations) is certainly a "best practice", but gets no mention.

    On the other hand, given your record of unusual applications of meaning
    to English statements perhaps the inappropriate title is just another
    manifestation of that.

    Richard.
     
    Richard Cornford, Oct 13, 2005
    #17
  18. Gérard Talbot wrote:
    > Michael Winter a écrit :
    >> On 12/10/2005 04:56, Gérard Talbot wrote:
    >>
    >> [The all collection]
    >>
    >>> Useful purpose for IE 5.x? Can you elaborate on this? what do you
    >>> mean...

    >>
    >>
    >> The getElementsByTagName method is not implemented properly in IE5.x.
    >> Passing an asterisk (*) will always return an empty collection,

    >
    > I didn't know that.


    This should not be particularly surprising as the '*' wildcard for tag
    names is not mentioned in the W3C Core DOM Level 1 standard, and IE 5
    was (at best) a DOM Level 1 browser. This is also true for Opera <= 6
    and NetFront 4, for example.

    <snip>
    > IMO, tricks based on + and -0 can not be the best recommendable


    They are not tricks, they are just type-conversion. An aspect of a
    loosely-typed language that authors need to appreciate. If forced
    type-conversion is wanted only two constructs can be recommenced; Unary
    +, because it is the fastest technique (so the best to use when speed
    matters) and passing the numeric string as the argument to the -
    Number - constructor called as a function, because it is
    self-documenting (and so should be used when clarity of source code is
    desired).

    It is often proposed that when Unary + is used the unary expression
    should be parenthesised so that the + symbol is not easily mistaken for
    addition/concatenation or typoed pre and post increment.

    > way to convert a string to a number. parseInt or parseFloat
    > should be used instead.


    Apart from their unexpected treatment of some forms of input (which
    should be precluded with regular expression validation of numeric
    strings where there is doubt) parseFloat and parseInt are the slowest
    method of turning a string into a number and less self-documenting than
    the use of the Number constructor (though javascript authors should be
    familiar enough with them for that not to be a real problem).

    > One example: Javascript Bible 4th edition by D. Goodman on
    > "Converting strings to numbers" p.78-79. Not one word on +
    > and - tricks: everything in his words clearly refers to the
    > use of parseInt and of parseFloat.
    > Is he way off the fact and the matter?


    Danny Goodman is so 'way off' that the best advice would be to burn his
    books unread. He has done enough harm to javascript authoring already.

    Richard.
     
    Richard Cornford, Oct 13, 2005
    #18
  19. Dr John Stockton a écrit :
    > JRS: In article <>, dated Tue, 11 Oct
    > 2005 23:15:34, seen in news:comp.lang.javascript, Randy Webb
    > <> posted :
    >
    >>Sidenote: The major problem with innerHTML is when the string being
    >>assigned is plain text. innerHTML has been proven, repeatedly, to be
    >>considerably slower that DOM methods or even the IE proprietary
    >>innerText property.

    >
    >
    > Which in the majority of cases is totally unimportant. Since the aim is
    > to change the information presented to the mind of the user, the time
    > taken is usually significant only if it exceeds about 200 ms.
    >


    The question remains though: what's the *best practice* (for beginners,
    intermediate users, etc) when the string being assigned is plain text.
    Most of us will grant you that the gain in time is negligeable if the
    string is short and if the user system resources are considerable.
    When is it best to use innerHTML? When is a DOM method a better choice
    over innerHTML?

    This page:
    innerHTML VS DOM.
    http://www.developer-x.com/content/innerHTML/default.html
    suggests there are more problems with usage of innerHTML.

    Gérard
    --
    remove blah to email me
     
    Gérard Talbot, Oct 13, 2005
    #19
  20. On 13/10/2005 00:30, Gérard Talbot wrote:

    > Michael Winter a écrit :


    [snip]

    >> Unless one is iterating through a collection, using numeric indices is
    >> not a recommended practice

    >
    > Matt K. explicitly states that numeric indices is a bad practice.
    > "Referencing forms using indexes, such as document.forms[0] is bad
    > practice."


    And I'm saying more-or-less the same thing. Just less strongly.

    [snip]

    >> As you were told in ciwah, validation is not a goal in itself. There can
    >> be justified reasons for writing invalid markup[1],

    >
    > I don't recall being told that.


    Which part?

    You certainly were told the former in the recent '3 questions on
    validation' thread. For instance, the first response by Travis Newbury:

    You seem to have missed the point that validation is a "tool" not
    a "goal"
    -- Travis Newbury,
    <>

    I'm saying the latter now, though others have in other discussions. So
    did Jukka in his article, '"HTML validation" is a good tool, but just a
    tool'[1], which he referenced in the same thread as the quote above.

    [snip]

    > A document about javascript best practices can not and should not rule
    > out/exclude people who serve XHTML document as application/xhtml+xml.


    Serving a non-trivial script with a document served as
    application/xhtml+xml is often a completely different kettle of fish as
    the objects models are different, and would warrant its own document.
    Anyway, if an author is knowledgeable enough to correctly
    content-negotiate a document, then they should know enough to correctly
    transfer remarks about HTML to XHTML.

    >> That is a better use of your time than worrying about a single attribute.

    >
    > Somehow the tone of your post has become personal. All my posts were
    > referring to the draft document.


    My apologies. That sentence wasn't directed at you. It was the sloppy
    use a of second-person pronoun meant generically in text that used the
    fourth-person in that situation, more often than not. The word, "your",
    should have been "one's".

    [snip]

    > So what's the big deal with numeric indice?


    It isn't a 'big deal', but an identifier is immune to markup changes
    whereas an index may not be. But still, and I reiterate (again), I'd
    recommend using element references wherever possible and avoid the issue
    entirely.

    > All I can read in the document is a simple directive in the document
    > regarding numeric indice: no explanation as to why such directive and no
    > recommended solution for XHTML-based documents.


    If an author wants to write valid XHTML markup, but needs to be told to
    use an id attribute in place of a name attribute (or see above), I think
    the author may need a career change.

    [A missing action attribute]

    > When should someone bring this up then? When a "HTML Best Practices"
    > document is released?


    Forms are designed to be submitted. The action attribute is used to
    specify where the data is sent. Ergo, an author is almost certainly
    going to include one, anyway. I doubt that any reader of Matt's document
    will stop just because he omitted it in a trivial example.

    I have no problem with him including a dummy attribute value, but it
    really isn't a big deal if he doesn't.

    And yes, an 'HTML best practices' article would be more on-topic. :D

    [Converting to number]

    > Ok, what about parseFloat() then? I mentioned it in my original post.


    It still does more than necessary with no added advantages in return.

    [snip]

    > IMO, tricks based on + and -0 can not be the best recommendable way to
    > convert a string to a number.


    Subtracting zero is a trick, and I don't recommend it either. However,
    the unary plus operator is not a trick.

    The unary + operator converts its operand to Number type.
    -- Section 11.4.6, ECMA-262 3rd Ed.

    > One example: Javascript Bible 4th edition by D. Goodman [...]


    Danny Goodman is not a recommended author in this group and neither is
    his book. I haven't read it, but from what I have seen from him, I'm
    inclined to agree.

    [snip]

    > Ok. Let me repeat what you've said so that no one gets you wrong. You
    > say Matt K. in that document is not defining a general rule regarding
    > the use of returning false in an onclick even attribute.


    That is correct. That entire section of the article only refers to A
    (anchor) elements. The references to 'link', 'anchor', or 'href' in the
    first three paragraphs (of five), plus the heading and examples should
    make that very clear.

    [snip]

    Mike


    [1] "HTML validation" is a good tool, but just a tool
    <URL:http://www.cs.tut.fi/~jkorpela/html/validation.html>

    --
    Michael Winter
    Prefix subject with [News] before replying by e-mail.
     
    Michael Winter, Oct 13, 2005
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. karim
    Replies:
    0
    Views:
    474
    karim
    Jul 13, 2003
  2. John Dalberg
    Replies:
    3
    Views:
    583
    samuelhon
    Nov 16, 2006
  3. Schemed
    Replies:
    0
    Views:
    271
    Schemed
    Apr 22, 2008
  4. Matt Kruse
    Replies:
    60
    Views:
    463
    Randy Webb
    Jun 13, 2006
  5. Chicken McNuggets

    Best book on C gotchas and best practices?

    Chicken McNuggets, Jul 31, 2013, in forum: C Programming
    Replies:
    9
    Views:
    275
    Fred J. Tydeman
    Aug 5, 2013
Loading...

Share This Page