Even better - we should ditch color monitors altogether. You know, to be edgy and different.
Turning off syntax highlighting
41–50 of 192 posts
Re: Turning off syntax highlighting
#42Yes, let's use roman numerals too lest we calculate too efficiently and be able to express more complex calculations more easily.
You mixed it up.
Syntax highlighting is like doing arithmetic using colored rods: https://groups.google.com/forum/#!msg/golang-nuts/hJHCAaiL0s...
Roman numerals is object-oriented design: https://groups.google.com/d/msg/comp.os.plan9/VUUznNK2t4Q/Ff...
Re: Turning off syntax highlighting
#43I like to highlight just the places where you are defining new variables/functions/types so that the definition is easy to spot. What is the point of highlighting keywords? I suspect that highlighting engines do it simply because it's easy to do, not because it's useful. It looks like this: http://david.rothlis.net/code_presentation/distracting_synta...
One of the points of syntax highlighting is to create visual patterns you can recognize. Highlighting keywords may help with this. Have you tried disabling keywords highlighting and seeing what difference it makes in reading your code?
Re: Turning off syntax highlighting
#44Earlier quoted context omitted.
I agree completely. On that note, I also consider `git add -A` to be horrible practice. Adding files manually makes you tons more aware of what changes you actually made, and also prevents you from accidentally adding extra files you don't want. I also recommend people to look at the Linux kernel git history for good examples of how to use git well. Even if you have no knowledge of kernel code (and most people don't)…
> I also consider `git add -A` to be horrible > practice. Adding files manually makes you tons more > aware Agreed, but I take it further than that - I always use `git add -p` because it forces me to read through everything, and make everything in the commit deliberate. Even if you think you just made a slight change to a file or two and definitely want everything, you'd be surprised how often it lets me pick up some…
I am in the other extreme: I always use `git add -A` (but I read the diff before) and avoid doing more than one thing in the first place (which would make me want to use `git add -p`). IMO it is an antipattern to do bazillion changes at once, and then do several commits out of it (unless you really know what you're doing) - because you commit a state of the repo that (probably) never existed. I prefer to do change, commit, do change, commit, and at the end do interactive rebase and perhaps squash some things together.
Re: Turning off syntax highlighting
#45Earlier quoted context omitted.
I agree completely. On that note, I also consider `git add -A` to be horrible practice. Adding files manually makes you tons more aware of what changes you actually made, and also prevents you from accidentally adding extra files you don't want. I also recommend people to look at the Linux kernel git history for good examples of how to use git well. Even if you have no knowledge of kernel code (and most people don't)…
I just don't understand why people use the git CLI. Git is too powerful a tool, using the CLI limits one of two things: your capabilities, or your productivity. Often times I see my coworkers screwing around with git trying to review diffs and commit their changes. One of two things happens: they spend longer than they should doing it, or they do it haphazardly. Sometimes they get it wrong. Just use a GUI. I use Sour…
> I'm confident the average git CLI user doesn't even know this is possible.
Your sibling commenters disagree.
Re: Turning off syntax highlighting
#46Slightly meta: Turning off the syntax highlighting entirely seems a bit hardcore to me, however, I always read each commit I do via git diff / pull request view, which does not have syntax highlighting (other than red/green for removals/additions), and I always strive to make the diff look good for each commit (which means, doing one thing at a time in each commit, and making sure it reads well). Unfortunately, not e…
Learning to this both after writing the code and being able to plan what chunks of works I do when is a game changer and really useful when you work on a team.
I sometimes find waiting until I am done working on something to break it up into small commits can be a headache.
Re: Turning off syntax highlighting
#47I only color comments and strings.
Same. Works well for me e.g. http://i.imgur.com/RMrslmu.png
Re: Turning off syntax highlighting
#48Not this again "We should remove all color from traffic lights and make people remember which position is what"
Surely this would make people slow down and pay attention or you know just crash more.
Re: Turning off syntax highlighting
#49I think a large part of the issue with syntax highlighting is that our "standard" for syntax highlighting is rather dumb. A few thoughts: - Who the hell would write prose by making all the verbs blue, the nouns red, and the adverbs green (or something to that effect). That's what we do for code. Something togglable a-la iA Writer might make sense, though. At the same time, I can sort of understand, though, because we…
Speakers use inflection to emphasize the important things in the message. In a single method, there might be a few lines of assignments and setup, a few lines to actually do what needs to be done, and then some formatting of a return value in the correct structure.
Maybe what we want to do is emphasize the few lines that matter the most. Right now, we try to break the methods down into smaller and smaller pieces, resulting in the “In Smalltalk, everything happens somewhere else” syndrome.
Re: Turning off syntax highlighting
#50I don't turn syntax off, but I hate rainbow in my IDE. I usually use bold for keywords, different colors for comments and string literals, underscore for class members (for Java). Basically that's all. I don't need any other highlighting, it's just a noise for me which makes it harder to read the code.
What I don't understand is that people want to highlight keywords. Bold is a very strong highlight compared to coloring it. However, keywords (if, while, return) can probably be guessed from the indentation alone. There is little need to guide my focus to them even more.