I like to take advantage of my tooling to make my life easier. Writing good code is difficult enough without imposing additional constraints upon yourself to make it more challenging.
[deleted]
Turning off syntax highlighting
121–130 of 192 posts
Re: Turning off syntax highlighting
#122Earlier quoted context omitted.
Don't you always have commits chains like "add debug printfs" "fix bug" "remove debug printfs"?
That's a scenario for branch-then-cherrypick :) Branch, write test to expose bug, add debug aids, fix bug, switch branch, cherry pick the test & fix, delete debug branch.
Or just `git rebase -i origin/master` and delete the unnecessary commits without additional branching.
Re: Turning off syntax highlighting
#123Earlier quoted context omitted.
> 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 use `git commit -a` a lot, but only after checking `git status` (or `git diff`), which is probably my most-used git command.
Those two A's have completely different meanings though (add all, commit amend), not sure I understand how it's relevant to the parent?
Grandparent is correct: "git commit -a" is --all, not --amend.
Re: Turning off syntax highlighting
#124This seems like old-is-new waxing, reaching for some reason the old way is better.
> Initially, turning off syntax highlighting felt weird. I couldn’t skip through the source that fast anymore and it became harder to read.
It does, that's the point of syntax highlighting. This isn't a good thing(tm).
> Even though this appeared to be an impairment I found it to be the strongest argument for making the switch. By forcing me to read the code more carefully, it made me understand it better
I tried not highlighting a bunch of times, it's called switching from my IDE to vi for whatever reason. It's not better for me.
Re: Turning off syntax highlighting
#125Earlier 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 get a lot of (good-natured) crap from other developers because I always use a graphical tool to view my git diffs and make commits. I realize that there are console tools like git interactive staging that provide similar functionality, but honestly I just like having a dedicated windowed application always running that is always the gateway for my code.
> I get a lot of (good-natured) crap from other developers because I always use a graphical tool to [...]
One of my colleagues uses PyCharm, while at the same time using Vim somewhere else (for both Python and not Python). This frustrated me a little every time he asked me to his terminal in a similar fashion I'm annoyed by somebody using GUI for the simplest task I could do in a single command. In both cases I try to keep comments to myself, at least now that I'm a little wiser than I was five-to-ten years ago.
It takes a lot of patience not to throw such "good-natured crap" if one is proficient with more-basic-yet-powerful tools. It needs wisdom to recognize that people do things their own way because it's more effective for them at the moment, and it's hard to change one's habits on a whim at arbitrary times. It gives me much better results to call others to my terminal to show them some interesting thing; they are in much better condition to learn a new Vim command or CLI tool (this way I successfully exposed two colleagues to AWK, what I planned for a long time).
Re: Turning off syntax highlighting
#126Earlier quoted context omitted.
Comments are the most important part of code. They should not be dimmed. If anything, they should be the only thing that is highlighted.
I'm arguing that dimming them makes them easier to see. Code and comments are interspersed, and are each harder to see when they're the same color.
I use a slightly more intense background color on comments to make them stand out while still being readable enough.
Re: Turning off syntax highlighting
#127Turning syntax coloring off was the best decision in my career. I have never looked back.
Writing programs all on a single line was the best decision of my career! The enlightenment writing everything on a single line imparted to me was nothing short of an epiphany...
Re: Turning off syntax highlighting
#128I 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…
> Given 100% control over typography, how would you format [code] to maximize readability
There was a book on this, whose title I'm blanking on. Anyone remember? Color wasn't an element, since it was an older book focusing on printing on paper.
Re: Turning off syntax highlighting
#129I think syntax highlighting probably evolved before editors and IDEs could flag coding mistakes. A lot of the rationale for it no longer applies, e.g. coloring strings a certain way so if you forgot the terminating quotation mark, the rest of the file would change to that color and you'd know you screwed up.
I haven't used syntax highlighting for years. My IDE highlights mistakes and compiler errors, and everything else is black. It's actually a lot easier on my eyes, and the errors stand out a lot more because they are the only colored parts of the text. I only use highlighting these days to separate tags from content in markup languages like XML and HTML, where I still find it helpful.
This is all personal preference anyway, and it doesn't matter very much. But I do encourage people to try going without syntax highlighting for a few days. You may find that you didn't really need it, or that it was compensating for sloppy coding, and you may not want to switch it back on at the end of the experiment.
Re: Turning off syntax highlighting
#130Slightly 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…
>Slightly 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)
...alas, some projects require 1 commit per pr, max...
...then again, if you do a 1:1 commit:change as default the rebase msg is much easier to structure :)