4 ms·

This is bad practice, at best it shows a lack of confidence in what you've written. At worse it shows you don't understand what's going on. Version control sho

This is bad practice, at best it shows a lack of confidence in what you've written. At worse it shows you don't understand what's going on. Version control shows the evolution of design, if you are leaving in dead code you need to take a step back and think about the real solution.

gh02t 12y ago
Does anybody know what Apple uses internally as their version control setup? I did some Google searching that seems to suggest they use Git, but I'm curious if anyone knows more.
- jarjoura 12y ago
  When I was there it was a healthy mix of CVS, SVN and git. Engineering wanted to move to git, so I would assume they are on the path to 100% git, annnnd.... probably already are at this point.
  - pixeloution 12y ago
    There is still some SVN floating about but its primarily git
    - jjtheblunt 12y ago
      There's a great deal in Perforce too; the P4 gui tools are excellent, by the way, at illustrating changes in source over commits, and are incessantly in use.
ssmoot 12y ago
I've heard this so much. Usually from people who reinvent the wheel five times over. I've never seen anyone dig through VCS history to gain a better understanding of code. And since presumably things change because the understanding evolves, I'm not even sure what the thought process is that would lead someone to do that. You comment out code because your understanding might not be perfect, you might want the option to easily roll-back, or even have a reminder that a particular change was made. You'll remove it in the next revision or two. So yeah. I've heard this before. It's complete and total nonsense IME.
- rohansingh 12y ago
  > I've never seen anyone dig through VCS history to gain a better understanding of code. git bisect, git log, and git blame are all indispensable tools. To counter your anecdote, I use them all the time and see others do so. There's really no reason to leave dead imports in a file.
- mconley 12y ago
  > I've never seen anyone dig through VCS history to gain a better understanding of code. I'm actually going through the ancient CVS history of Mozilla Firefox in order to learn about a relatively poorly understood piece of code that's still in there to this day: http://mikeconley.ca/blog/2014/07/07/docshell-in-a-nutshell-part-1-original-intents/ http://mikeconley.ca/blog/2014/07/07/docshell-in-a-nutshell-... and http://mikeconley.ca/blog/2014/08/10/docshell-in-a-nutshell-part-2-the-wonder-years-1999-2004/ http://mikeconley.ca/blog/2014/08/10/docshell-in-a-nutshell-...
- the_why_of_y 12y ago
  You never wonder why particular lines of code happen to do exactly the things they do, in the exact order they do them, when your intuition would tell you that it would be a third as many lines if only the code called this or that utility function, or that it obviously doesn't handle the particular corner case of a new bug report? You must work on unusually well commented code bases then; I wouldn't get anything done without git log -p... at a minimum you will quickly find out which generation of maintenance programmer added the odd code in question and what (if any) bug it was intended to fix, so you don't break that use-case. Well, unless you're out of luck and the first generation of them lost the first 5 years of SCM history, that is...
  - ssmoot 12y ago
    No. If the intent behind the source code you're actually looking at is not apparent, then realistically, looking at it's history is probably equally useless. If there aren't tests or specifications to cover the code, I generally assume any bugs are because of a lack of understanding and proceed from there. Scrolling backwards through history and looking at progressively more naive or prototypical implementations isn't going to tell me anything except the code was likely underspecified IME. Comments are infrequent, but when I write them, they're usually to try to clarify particularly complex implementation detail. Not to communicate requirements. Comments aren't the ideal place for that IMO.

gh02t 12y ago

Does anybody know what Apple uses internally as their version control setup? I did some Google searching that seems to suggest they use Git, but I'm curious if anyone knows more.

jarjoura 12y ago
When I was there it was a healthy mix of CVS, SVN and git. Engineering wanted to move to git, so I would assume they are on the path to 100% git, annnnd.... probably already are at this point.
- pixeloution 12y ago
  There is still some SVN floating about but its primarily git
  - jjtheblunt 12y ago
    There's a great deal in Perforce too; the P4 gui tools are excellent, by the way, at illustrating changes in source over commits, and are incessantly in use.

ssmoot 12y ago

I've heard this so much. Usually from people who reinvent the wheel five times over. I've never seen anyone dig through VCS history to gain a better understanding of code. And since presumably things change because the understanding evolves, I'm not even sure what the thought process is that would lead someone to do that. You comment out code because your understanding might not be perfect, you might want the option to easily roll-back, or even have a reminder that a particular change was made. You'll remove it in the next revision or two. So yeah. I've heard this before. It's complete and total nonsense IME.

rohansingh 12y ago
> I've never seen anyone dig through VCS history to gain a better understanding of code. git bisect, git log, and git blame are all indispensable tools. To counter your anecdote, I use them all the time and see others do so. There's really no reason to leave dead imports in a file.
mconley 12y ago
> I've never seen anyone dig through VCS history to gain a better understanding of code. I'm actually going through the ancient CVS history of Mozilla Firefox in order to learn about a relatively poorly understood piece of code that's still in there to this day: http://mikeconley.ca/blog/2014/07/07/docshell-in-a-nutshell-part-1-original-intents/ http://mikeconley.ca/blog/2014/07/07/docshell-in-a-nutshell-... and http://mikeconley.ca/blog/2014/08/10/docshell-in-a-nutshell-part-2-the-wonder-years-1999-2004/ http://mikeconley.ca/blog/2014/08/10/docshell-in-a-nutshell-...
the_why_of_y 12y ago
You never wonder why particular lines of code happen to do exactly the things they do, in the exact order they do them, when your intuition would tell you that it would be a third as many lines if only the code called this or that utility function, or that it obviously doesn't handle the particular corner case of a new bug report? You must work on unusually well commented code bases then; I wouldn't get anything done without git log -p... at a minimum you will quickly find out which generation of maintenance programmer added the odd code in question and what (if any) bug it was intended to fix, so you don't break that use-case. Well, unless you're out of luck and the first generation of them lost the first 5 years of SCM history, that is...
- ssmoot 12y ago
  No. If the intent behind the source code you're actually looking at is not apparent, then realistically, looking at it's history is probably equally useless. If there aren't tests or specifications to cover the code, I generally assume any bugs are because of a lack of understanding and proceed from there. Scrolling backwards through history and looking at progressively more naive or prototypical implementations isn't going to tell me anything except the code was likely underspecified IME. Comments are infrequent, but when I write them, they're usually to try to clarify particularly complex implementation detail. Not to communicate requirements. Comments aren't the ideal place for that IMO.