Unfortunately, not everyone I work with reads their code (yep, they write-commit-push-and-forget!) which sometimes makes code review a not so nice experience.
Please, please, read your diffs before sending code for review.
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) it's still extremely clear how each commit makes a single change and is fairly easy to review. Now, the Linux kernel has the luxury of being able to demand people fix their commits, but that's not to say you shouldn't strive to reach similar states in your commits.
> I also consider `git add -A` to be horrible
> practice. Adding files manually makes you tons more
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 aesthetic change, comment change, or dependency version bump that's completely unrelated to the commit message I'm about to write.
The fact that `git` makes changing your history around easy make this workflow work fairly well without too much extra overhead to achieve a clean history. I don't disagree that doing it right the first time is really the best way to do it, I just don't find that it really works out that way in practice.
The tricky thing is that when doing several things without committing, sometimes you can end up in a state of the repo where you can't split the work done into nice commits anymore (because you might have modified same part of code multiple times).
Maybe this step-by-step working scheme was influenced by svn that cannot commit partial changes, but it seems a good practice on its own, especially in total refactoring.
> and avoid doing more than one thing in the first
> place (which would make me want to use `git add -p`)
Maybe your better at avoiding it than I am, but I find it to be easily done.
git add -A
Branch, write test to expose bug, add debug aids, fix bug, switch branch, cherry pick the test & fix, delete debug branch.
The state doesn't exist in the repository until the code has been committed - so your statement is a little backwards. Sure the code might never have only had that edit in it, but the repository has no changes until a commit is made.
If a bug is found, the invalid state of the intermediate commits might make it harder to isolate the change that caused the bug.
That being said, I generally use "git add -p". I've gotten accustomed to trying to have clean commits. Although, sometimes the changes have enough complexity that breaking them up becomes too painful and I end up with a few messy commits. Such is life.
Then, `git show` before you do `git push`.
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 SourceTree and often find myself committing individual lines or chunks in my files instead of the whole file. I'm confident the average git CLI user doesn't even know this is possible. I can do massively complicated commits with ease because I can see every single line that has changed right in front of me.
I just don't understand the fetishization of source control via CLI. In all likelihood it doesn't make you more productive, and it's probably less accurate unless you really know you way around git.
I'm much more productive using a couple of git commands that I can type in a few seconds, rather than hunting for things in menus and dialogs for ages.
> committing individual lines or chunks in my files instead of the whole file
That's really git 101. I'd expect if you haven't learned to do that via the CLI then maybe you gave up too soon and jumped straight to GUI? `git add -p .` is very easy to use.
Whereas in the CLI, complex operations are difficult but possible; trivial operations are also difficult but possible. :)
Maybe it is of limited use for non-emacs users, but imho it's a fantastic way to use git with a perfect balance between making simple things very easy to do and allowing (almost) anything you can do with the CLI while providing excellent visual feedback.
That said, since I discovered Spacemacs, I'm also enjoying using Magit - the "evil" control scheme for it is great, too.
But yeah, I picked it up after quite some time working in Emacs, and the keybindings feel natural. Perhaps it would be very different for somebody new to Emacs.
1. gitk is the handiest way to undo the occasional accidental commit ("reset index, leave working tree untouched"). yes, i know there's bound to be a CLI way; no, i can't be bothered to look it up and remember it when i have gitk right there and it's not a mainstream use case.
2. git-cola does interactive commits way better than the console interface does.
You mean `git diff`? I'm sure it comes down to a matter of preference, but claiming that using git from a command line slows you down or limits your capabilities only makes sense if you rarely touch a command line (a bit strange for a developer). Plain old git from the command line is functional and actually quite user friendly. Add your own aliases and some kind of git shell and you can fire off a complicated commit as fast as you can sensibly review your diff — all without lifting a finger from the keyboard.
GUI git tools are nice for visualizing feature branches, but for the basic day-to-day workflow the CLI is much more productive.
Surely the exact comment, with the roles of 'CLI' and 'GUI' switched, could be made without anyone necessarily noticing. The anecdotal evidence of what works, and doesn't work, for you should not, I think, be regarded as any particular evidence of what does work for anyone else, much less what can work for everyone else. (As has already been pointed out, your child posts are full of responses from people with other experience.)
There are definitely people out there (I've seen them) that would be better served with a GUI because they really can't be bothered to learn how to use the `git` CLI well (Or just use `git` well in general). But at the same time I'm tons more productive with the CLI vs. GUI.
That's fine, but on the other hand, a typical GUI limits both your capabilities and your productivity.
About the only interface I prefer over git CLI is magit in Emacs. It's unlike your typical GUI, because you don't have to click at anything (keyboard-operated), and it exposes like 99% of git inside a well-thought-out text-based UI that adds just the right amount of interaction and editor integration. Using magit is incredibly efficient, much faster than even using CLI git.
> I just don't understand the fetishization of source control via CLI. In all likelihood it doesn't make you more productive, and it's probably less accurate unless you really know you way around git.
If you don't know your way around git, chances are you're going to seriously screw things up via GUI and you'll have no idea what happened or how to fix it. Starting from CLI is a good way to actually learn the tool, which I believe is crucial regardless of what interface you'll eventually be using.
Your sibling commenters disagree.
That said, there's a lot you can't do easily or at all from the GUI. Rebases, surgically reverting a series of commits from a bad merge, re-writing branches, blame, bisect, reviewing the history of a single file, checkout of a specific version of a file from a previous revision; there are a lot of things that I can do easily from the CLI that I don't know how to do or don't care to do from a GUI.
Use the right tool for the job. The GUI is great for common tasks and the CLI is great when you need more power.
the rest is command line git.
With command line completion is pretty good and fast.
Then what happens when they update their GUI? Oh you have to learn it all over again.
That being said, I do on occasion open a GUI if I have to do a complicated merge or something like that but for basic operations why would you need it.
I use `git commit -a` a lot, but only after checking `git status` (or `git diff`), which is probably my most-used git command.
Side note: `git status` is not a good means of "knowing what was changed". I see others use it constantly (doing git status -> git add . -> git commit) and it'a sloppy IMO.
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).
...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 :)
I sometimes find waiting until I am done working on something to break it up into small commits can be a headache.
You get the diff in the editor when you write commit message.
Similarly, before doing something complicated at work, please talk about it with a coworker first. Last thing I want is to try to decipher a complicated piece of code without a good motivator as to why I'm doing so. Advanced warning is a great motivator.
> I couldn’t skip through the source that fast anymore and it became harder to read
Which, yes all the modifications to style (which is only his own code by the way) helped factor out. But I bet he'd be even better now with highlighting that he's made these additional changes to his style.
I worked for years without syntax highlighting. I am much more efficient with it for exactly the reason quoted. To each their own, but having visual cues to help is not a bad thing. I want my job to be easier.
I used to program black on white, then I was converted after jetbrains came out with an excellent dark theme with huge color variants that make code pop even better.
I'll never go back; I want my work and job easy, not made harder.
Yes, working in a team is definitely a different endeavor. If your teammates or organization aren't open to changes to the style guide then I wouldn't recommend turning syntax highlighting off.
- 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're almost always in "edit" mode for code, very rarely in pure "write".
- I find having lint-errors highlighted provides a similar nudge to the "squiggly-red underline spellcheck".
- Our editors aren't configurable enough with regards to typography. I like to use subtle weight changes, highlighting "headings" and whatnot, and very few tools seem to make that change available.
- Semantic highlighting seems super interesting, but I haven't found a tool that I like yet.
One project I'd love to see is to get a bunch of folks together to do some proper layout-by-hand on code -- Given 100% control over typography, how would you format it to maximize readability, minimize distraction, highlight relevant contextual knowledge, etc? And then work to push tools in a direction that they support configuration to allow for said tasks.
Slightly off topic, but I think doing this could actually be useful for learning languages, especially highly inflected ones (if you extend the color coding to account for gender, case, etc.).
He could lead if he would get the lead out.
A bass was painted on the head of a bass drum.
That that that that boy said is not that that that that boy said.
Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo buffalo.
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.
Likewise, highlight macros in C and make them different to variables/functions.
You can see here that the Monokai theme supports about 20 tokens and doesn't differentiate much between scopes: https://tmtheme-editor.herokuapp.com/#!/editor/theme/Monokai
Personally, I prefer highlighters that do something to highlight variables differently, like this variant of Monokai (ie around line 45 for the JS example): https://tmtheme-editor.herokuapp.com/#!/editor/theme/Monokai...
What you are describing sounds like regular syntax highlighting to me.
This is my current theme: http://imgur.com/a/cQbWL
You can see the level of customization available fits with what you described.
And it has really helped many times in the past, preventing all sorts of silly mistakes that could have been hell to debug. Like shadowing a variable :)
I've had a similar thought for several years now. Want to hash out some ideas? You can contact at my site wanderingstan.com or on twitter @wanderingstan.
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.
The last time I could bare not using syntax highlighting I was still on MS-DOS.
Since Turbo Pascal 7 (released in 1992), syntax highlighting is a must have on my programming environment.
But I understand when we are talking about vim, people prefer an hardcore experience.
I am using Vim dynamically, calling it out of CGIT. For example:
When you access this file, CGIT runs a syntax highlighting shell script where you can hook in multiple approaches (e.g. based on file suffix). I hacked this script to run Vim via Expect, to load the text and save the HTML with :TOHtml.
As you can see, the TXR pattern language and TXR Lisp are nicely separated in the output. The identifiers are colored differently---even in cases when they are the same! Look for a purple (do ...), which is a directive in the TXR pattern language to enclose and evaluate a bunch of Lisp, and green (do ...), which is a totally unrelated construct in TXR Lisp: one of the forms that support explicit partial evaluation.
When I'm coding in TXR, Vim is quite accurate in identifying mistakes like string literals not being closed and parentheses not being balanced and such, or various tokens being malformed and whatnot. It can figure it out in spite of levels of nesting. It significantly reduces such errors.
When I could use Turbo C on my own computer in the 1990s, syntax highlighting just came along for the ride. I learned vi from Watcom. I used vim. I wrote in perl, and PHP. I also learned Emacs. I wrote in Common Lisp. Syntax highlighting just stayed on.
And then I saw someone do something I had never seen before, and I wasn't sure how to do, and I noticed they weren't using syntax highlighting.
So I turned it off.
I would sometimes use ed to make changes to programs since I can see what I was working on before I needed to make a change, so I don't think it was doing anything for me, but at the same time I don't think I ever thought about syntax highlighting until I tried to work with dense code.
I do try consciously to improve myself, but nobody knows how they program and how to get better. The only strategy that has worked reliably: If I see someone do something I cannot do I try their methods until it makes sense in my own mind.
I've tried to write about this previously, but most programmers are hostile when seeing someone do something they can't do, rather than just trying it, they make up all sorts of reasons why they don't need to --"it's unreadable" is extremely common, but questions abou is a new one on me.
As it stands: I don't understand syntax highlighting. I'm pretty sure that syntax highlighting doesn't do anything for me in the best case. Maybe. But is it bad? Is turning it off necessary to being a better programmer? I got better when I turned it off, but it really might be a coincidence. I don't know.
: http://kparc.com/b/a.c but not exactly.
I know I prefer a much more muted colour scheme now than I used to. I still like my syntax highlighting but it's more hinting than glaring RGB confetti.
Being hardcore doesn't imply that the syntax coloring is bad.
Comments are a shade that's near the background: I can read them if I focus on them, but otherwise they're not present when I'm reading code
Strings are a colourful colour, because the next visual distinction I want is between what's an operation or name, and what's data or literal. Numbers don't get this treatment because they're sufficiently obvious on their own.
The base text colour has a small distinction between keywords (darker) and everything else (lighter).
Sometimes I'll pull in another colour if I'm in something like Python for things like decorators, to create a distinction between code and meta-code.
This takes care of 95% of the visual distinguishing that's useful, and the rest is noise that adds cognitive load to track. As a bonus, because it's common to all languages in which I work, switching is easy because almost every language breaks down nicely between these categories.
Comments are for holding details: I shouldn't need them to understand code, at least superficially/structurally. But they should be there if I need to drill down on something a bit, and making it so that focusing on that extra detail is easily skipped or applied makes the overall code reading much more fluid.
"We should remove all color from traffic lights and make people remember which position is what"
I have gone for a more reserved theme in my editor lately. Currently on solarized again, but probably going back to zenburn soon.
Accident rates dropped sharply.
This is not true in source code. Syntax highlighting "helps" you to spot strings, numbers, keyword arguments etc. faster. But normally this is not what programming is about.
The point of colors in syntax highlighting, to me, is not to have a handicap, it's to read the code at the fastest speed possible. No one who is so new to an editor or a language should have the unrealistic expectations to understand the colors and read at full speed in their first hour of gazing.
They're really not. See also: millions of red-green colorblind people.
The top one is stop, the bottom one is go.
It's actually really uncommon to be completely unable to see colour; mostly it is just a problem to be able to distinguish colours.
.map(|bline| UnicodeSegmentation::graphemes(bline, true)
.map(|line| wordwrapline(&line, maxline, maxword))
What editor are you using where the highlighter doesn't identify user-defined types, member functions, namespaces, local variables? Maybe you don't realize it has these capabilities because it's configured to highlight them with the default?
When I joined a Java shop for the first time I was all gung-ho about sticking to my 80x24 terminal and emacs and to heck with the point-and-click crowd who couldn't do their work without a graphical UI. Then my new manager got me to try Eclipse for a week. I humored him and discovered that I was an order of magnitude more productive with Eclipse's semantic features like on-the-fly compile error underlining, code autocomplete, and navigation. It really was a humbling experience.
I think that's the right approach. Different situations afford different tools. In normal usage, reading only in a single color is a real relief to me; but of course it's typically easier to find missing delimiters and such with syntax highlighting.
I've had this shortcut in my vim configuration for a very long time and I use it frequently:
nmap <F11> :if exists("syntax_on") \| syntax off \| else \| syntax enable \| endif \|<newline><C-g>
I have come to think that it's the same with programming languages: Different languages require you to type different things explicitly. Sometimes that's beneficial but often it hurts. For example, typing a function signature is much more convenient in python (just variable names), but when debugging the explicitness of a more rigid type system often helps finding bugs. Similarly typing "const" or the precise type of integer is really annoying in many situations. It's visually distracting and shifts the focus on alignment or ordering of statements, instead of the problem to be solved. On the other hand, sometimes these things are just important. It would be very nice to have a programming environment where these details can be hidden most of the time and only turned on when really needed.
It looks like this:
Eclipse - no colors for different things, hard to find what I'm looking for (if I compare to the Emacs example, if I was looking at this code trying to figure out what members this class has I'd be looking for brown and finding it much more quickly)
Emacs - terrible color scheme, both the brown and the green are too bright, not enough contrast to read.
Proposed - all the bold text hurts my eyes and distracts me from everything else.
In my crazy theme almost every "thing" has its own color, and it is very easy to find what I want by looking for the right "thing" or combination of things.
As an example for where highlighting keywords would help (which is what you mentioned in your post), if I'm looking for "that for loop that does the main logic" I'd look for the place with the small blue blob on the left and a long bright blob to the right (if it was an "if" likely both blobs would be smaller ;)).
I remember feeling like the game changed when I went from grey and yellow on black to grey and holy crap other colors for other things on blue from turbo pascal 3 to 7. You can't take it back from me now. I've had my syntax highlighted for 2/3's of my life now, I'm not giving it back.
Syntax highlighting is like doing arithmetic using colored rods: https://groups.google.com/forum/#!msg/golang-nuts/hJHCAaiL0s...
Roman numerals is object-oriented design:
> 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.
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.
As someone put it, it feels like "broscience".
I felt syntax highlighting was a gimmick that distracted me from my Monaco 10 with no anti-alias perfection.
If I needed to do some repetitive editing beyond a simple find/replace, I'd write a small shell script. I was kind of proud of my minimalism. You can do a lot with native Carbon/Cocoa key bindings alone. Life was good.
Then someday I saw a video of someone doing crazy work in Vim. Flying. I had to learn that.
I forced my self to use Vim exclusively for one job, from beginning to end.
I kept watching similar videos to get over the nightmarish frustration that is anyone's first week or so in Vim.
But after that, I was completly hooked.
However, I still have warm feelings when I open some code in TextEdit. Black, 10px Monaco text over a 90 by 30 white background. Ah.
I looked over an old edition of Halliday+Resnick once, a well thought of lower division physics book. The text was substantially the same but it was black and white. This meant no syntax highlighting and also no glossy paper. The result was a LOT easier to read.
Glossy paper is a designery thing to do for deeper blacks but it's less readable. Indeed that's why actual designers like matte finish MBPs, because you don't want to read with a 20% opacity of yourself staring at you.
Acknowledge that it's a hipster thing to use vi and fixed gear bikes, and carry on with your life.
However, some folks is pushing the syntax highlighting into realms of an art piece. I had a coworker that would using bold, italics, different font sizes, as well as colours.
For me this is a use case for conditional highlighting.
What I do in my code additionally is to avoid block comments. So you can differentiate them better from your code.
E.g. looking at Python code, it highlights 'def', 'if', 'else', 'elif', 'for', 'while', etc. in orange, function identifiers in cyanish and literals (integer, float, strings) redish (on terminal with blackish background).
If I look at code, it helps me to find the beginning of a function and the parts where logic branches (conditions, loops, etc.) start. Some time ago I wrote code without highlighting and although it is obviously possible I found it harder (i.e. it took me more time) to navigate for my eyes. Maybe just using bold or italic would be enough, though.
However thinking about it, it might be a nice experiment to highlight identifiers with a unique color (or at least highlight all occurrences of an identifier below the cursor - I think Eclipse does something like that).
Comments are pretty much universally "skimmable" if what you want to get at is the code, and also completely unrelated to actual code (other than describing it), so I think they deserve their own color and that it is helpful. Also, conversely comments in their own color stand out from the code so that if you're looking for descriptions, they are easier to find.
Colors also being useful for constant values (strings and numeric ones alike) because at least I really want something hard coded to stand out. Sometimes it should be hard coded, sometimes it shouldn't, but pretty much always, what the hard coded content _is_, is of interest.
As one of those programmers who were long ago forced to use no syntax highlighting (because monitors were monochrome), I say no thanks.
Unless the color scheme you were using really was so garish that it hindered your ability to improve your skills as a software engineer, in which case you could probably find a more subtle color scheme that would give you the same benefits as turning it off did. I've heard great things about the solarized color schemes. I use wombat myself.
So I use this. https://github.com/Kareeeeem/vim-walou
There's more stuff like it but I wanted to pick my own gray values and dislike pure white on pure black.
But I can see the benefit of forcing you to make your code more readable in general.
I tried no-syntax-highlighting for a while, but found that a little bit is nice.
- Great! Now we can finally get things done and stop bikeshedding!
- Now about that syntax highlighting of yours...
Most people simply highlight dumb stuff in their code.
For example, comments often have a bad contrast and stuff like brackets, curly braces or parathesis have high contrast.