67635 - "readability" keyword

Status: RESOLVED WONTFIX

(bugzilla.mozilla.org :: Administration, task)

Description

[Jesse Ruderman]

I think bugzilla should have a keyword for code-readability bugs.  Having this 
keyword would encourage people to file bugs for code readability, which would 
lead to more readable code, which would hopefully lead to:
- a decrease in the number of regressions.
- an increase in the number of code-level contributors.

Most of the bugs in this category would be "add comments", "remove hacks", and 
possibly "add references to documentation from code".  "Write documentation" 
bugs would remain in the Docs/Mozilla Developer component.  "Refactor code" 
bugs would be likely to get both this keyword and the footprint keyword.

Examples of bugs that would be marked with the "readability" keyword:

bug 46405 one-line patch made code diverge from a comment on the same line
bug 65415 nsWindow.cpp has given timeless nightmares
bug 67608 magic number 0x8000000 in mailnews javascript

Comment 1

[Jesse Ruderman]

Many of the bugs with "cleanup" or "clean up" in their summary would also get 
this keyword.

Comment 2

[timeless]

i agree.

Comment 3

[Andreas Franke (gone)]

This bug is related to bug 65558 "codelevel keyword". Since people don't like
that one, I vote for adding this one ("readability") instead.

I expect that many of the candidates for "codelevel" will be "readability" bugs,
thus having this keyword will help a lot.

Are there bugs that do not qualify for "readability" but do qualify for
"codelevel" (i.e. be invisible to the user)? Would it be appropriate to have
keywords for those bugs, too?

See also bug 65965 "Bug type classification (based on keywords?)".

Comment 4

[Jesse Ruderman]

Here's another one: bug 70299, a==b?c:d often under-parenthesized, should 
(hopefully) be (a==b)?c:d in each case for clarity.  70299 was filed because a 
mostfreq bug (bug 51237) was recently found to be caused by the code 
(idleport == usingProxy ? proxyPort : port).

Comment 5

[Keyser Sose]

I agree i am sick of having to ask developers all the time and really want to be
able to read code without having to refer to someone all the time. This would
allow us to check in comments without having to go through the whole review process.

Comment 6

[timeless]

i'm not quite sure how this could get easier checkin paths for such bugs, i 
know that comments usually need careful scrutiny because it's easy to mess up 
English.

Comment 7

[Grey Hodge (jX)]

Ok, around 8:25pm EST on Nov 18 2001, I made a rather simple statement in
reference to this topic, to which timeless and ksosez seemed to heartily agree:

1. Proper grammar and spelling while helpful and desirable in comments, should
NOT be a blocker to a patch. It can be easily corrected.

2. Correction of comments should not need the same level of review as REAL code
patches. r= should be more than sufficient for spelling/grammar comment
correction patches _AND_ if the comment patch is by the same author of the
original patch being corrected, no r= should be needed at all.

This is the most important point to what I said. As timeless then commented, it
only makes sense. "Since I know what I meant to do, and someone agreed I meant
to do it," all I'm doing is making my comments more clear to others.

Comment 8

[Hixie (not reading bugmail)]

->me

Comment 9

[Hixie (not reading bugmail)]

I don't see how a keyword would help here. Why would you search for a bug based
on this keyword? Seems to me like this would be something to speak to
[e-mail] about.

WONTFIX for now unless someone can explain why a _keyword_ would help.