[HN Gopher] Syntax highlighter is wrong (2014)
___________________________________________________________________
Syntax highlighter is wrong (2014)
Author : kqr
Score : 31 points
Date : 2022-09-07 09:04 UTC (13 hours ago)
(HTM) web link (jameshfisher.com)
(TXT) w3m dump (jameshfisher.com)
| wodenokoto wrote:
| I disagree with every single point.
|
| I don't need help with reading comments. I need help with reading
| code. Highlighting comments distracts me from what I need to
| focus on to read. The idea that comments are bad, is also one I
| disagree with.
|
| WRT to git diff, I intuitively understood green is added. No one
| had to tell me. The two "better" diff examples would cause me to
| misunderstand or not understand intent.
| rockemsockem wrote:
| This +1000. By graying out comments the editor/site makes it
| much easier to separate these two separate-yet-interleaved
| streams of information. I don't want a big ugly call-to-action
| on every single comment.
|
| This guy seems like he should just customize his own syntax
| highlighting and diffing tools and be done with it.
| delusional wrote:
| I highlight comments bright red in all editors, and it's
| really no different in terms of "filtering into separate
| streams". What it does significantly change is my initial
| approach to entering foreign code. Instead of immediately
| reading the code, my eye is drawn to the comments, often
| providing me with insightful commentary that then guides me
| in understanding the code. As a bonus, it has also made me
| more sensitive to outdated comments, which I views as a plus.
|
| Of course, comments also often contain the hidden assumptions
| or limitations of the algorithm that were too expensive to
| check. Often the comments actually do contain the bug you're
| looking for.
|
| I suggest you give it a shot. I didn't expect it to make as
| much of a difference as it ended up doing.
| kevin_thibedeau wrote:
| > red means bad and green means good. This association is cross-
| cultural, probably universal, and probably as old as the hills
|
| Couldn't be more wrong on this one.
| tuetuopay wrote:
| I wouldn't be as opinionated as OP. While I do agree that javadoc
| style comments are a curse we should get rid of, I find comments
| inline with code to be better a bit tuned down. Usually, the
| comment is useful when you don't grasp why a particular line is
| there. You notice there is a comment, so you read it. It's better
| to get an overview of the code, then drill down to its details
| with the help of comments. But those did not get in the way for
| the initial readout to get the big picture.
|
| IMHO it's the same reason editors offer folding functionality for
| code blocks. You get a big picture, then drill down to it,
| eliminating some clutter. For example, take Go's infamous `if err
| != nil { return err }`. I don't need to know every single one of
| them in a piece of code to get the big picture, so them being
| folded is good. Then upon further examination, I can expand them
| to see whether any special error handling is done at some place
| and why.
|
| For diffing colors, that's why I prefer a good side-by-side
| viewer with syntax highlighting. The default unified diff output
| is pretty useless when more than 2 consecutive lines changed.
| That is something that GitLab and others get right: side by side,
| changes to a line highlighted to tell "hey, only this word in the
| line changed, but it still count as the whole line being
| replaced".
| cogman10 wrote:
| > While I do agree that javadoc style comments are a curse we
| should get rid of
|
| Meh, I think javadoc is somewhat antiquated but otherwise an ok
| markup language for documentation. I do like that newer
| languages seem to have switched to a version of markdown for
| documentation.
| davidkunz wrote:
| I actually like that comments are usually toned down. They don't
| cause runtime exceptions and compiler errors, they don't disturb
| the program flow, they are not the cause of the bug I'm trying to
| fix. Just some hints to help me understand the code. For really
| important comments you can still use `TODO`, `FIXME`, etc. which
| most editors highlight more.
| marcosdumay wrote:
| Maybe we editors should include a REALLYIMPORTANT flag too. But
| the fact that I never thought about it before reading that
| article suggests it's not really important.
| thatswrong0 wrote:
| Agreed. Maybe I've had this wrong most of my programming
| career, but comments are usually for explaining the "why" of
| code if the code isn't that obvious by itself (and if this is
| the case, I usually try to refactor it first). It's rare that
| my comments ought to take precedence over the code itself.
|
| If I do have something REALLYIMPORTANT (which is
| exceptionally rare), I plaster it all over so that it's
| practically not missable (esp. in code review). Sure,
| highlighting _that_ comment might help a bit during
| development, but I really don't think that use case is worth
| highlighting _all_ code in that case. But it could be a
| 'nice-to-have' for syntax highlighters.
| hydrolox wrote:
| I'm not sure if red and green necessarily have a negative and
| positive connotation to me. First, red and green are often colors
| for + and - and second, you can read the code you need and see
| why it was deleted.
| marcosdumay wrote:
| It's funny, because those colors were clearly picked exactly
| because they have their positive and negative connotations,
| used as a metaphor for literally positive and negative changes.
|
| That's the same reason people use them on numbers too.
| secondcoming wrote:
| But deleting code (a red diff) is the most positive code
| change anyone can make
| Izkata wrote:
| Think of it more as state instead of transition: The code
| in red was bad so it had to be replaced with the good green
| code.
| ridiculous_fish wrote:
| Are there any editors which lay out comments on the side of the
| code? Or perhaps one that toggles their visibility?
| bhaak wrote:
| The example from Martin's book looks odd to me.
|
| The comment is AFTER the code that it is commenting on. I can't
| remember seeing this before. Only before or at most at the end of
| the line.
|
| Is that custom in any programming language community?
| Noughmad wrote:
| The opening is already completely missing the point. In Bob's
| book, the comment is highlighted because the paragraph is talking
| about the comment. Drawing a red circle around something you want
| to point out doesn't mean that that thing always needs a red
| circle around it.
| _bohm wrote:
| Similar post: https://www.benkuhn.net/syntax/
| dvh wrote:
| When syntax highlighter is wrong, I do the // "
___________________________________________________________________
(page generated 2022-09-07 23:01 UTC)