Modern Java is downright painful to develop longhand, in a regular text editor.

Ditto C#.

Writing c++ is painful without IDE as well.

Come to think about it, the same can be said about Objective-C

Honestly, every language I've ever used it painful without an IDE> I should never ever have a typo in my code. "Oh, I meant to say stackFrame, not stackFram... silly me". If that happens, your dev environment is broken.

The downside of that kind of thing is when you misspell something in the header file and then auto-complete it throughout the code as you write, never noticing the typo until after you've checked it in and your peers start mocking you.

First, how do you check-in w/o code review? Someone else will spot the typo.

Second, to fix the typo, fix it in one place, and click->"rename" and it renames it everywhere else.

Last, if your IDE has spellchecking support, it will let you know that part of your name does not exist in the dictionary.

My response was mostly tongue in cheek. But I'm curious... where do you work that required code reviews before every commit? Seems like an awful lot of bureaucracy. For my projects I usually set up post-commit code review systems.

I'm at a startup now. But I think you'll find most of the big shops you know about, like Google and MS, generally practice pre-commit review.

Open source projects often will do post-commit review. The review process is viewed as friction, and they don't want to block contributors due to the review process.

I personally prefer pre-commit review, although post-commit is a legitimate option (one I admittedly wasn't thinking about at the time).

So where do developers checkpoint their work until the official commit?

Either:

The smarter ones have to maintain a second source control archive (unless they are allowed to make personal branches, in which case the "public commit" is really just a merge, and probably a good thing),

or

the dumber ones just work without a net, loosing changes, and/or having to manually back out edit and test sessions that didn't go as well as hoped.

Oh, and I just realized I'm replying to the same guy about this.

>> how do you check-in w/o code review?

Early, and often, that's how. Surely you don't forbid a dev from saving his/her work (where it's backed up) and keeping a stream of "undo" checkpoints in the repository until only after somebody else had a chance to look it over???

Now, it does make sense to have a review before merging a development branch to a release candidate, but not to block check-ins/commits in general.

OK, so I've known senior staff who did want to have just this sort of restriction, and I found it foolhardy then, as well.

Exactly. These are simply memes. Not to be taken seriously :)