4 ms·

Ditto C#.

by presidentender 16y ago

Ditto C#.

didip 16y ago
Writing c++ is painful without IDE as well. Come to think about it, the same can be said about Objective-C
- kenjackson 16y ago
  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.
  - __david__ 16y ago
    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.
    - kenjackson 16y ago
      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.
      - __david__ 16y ago
        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.
        kenjackson 16y ago
        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).
        Roboprog 16y ago
        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.
      - Roboprog 16y ago
        >> 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.

Ditto C#.

didip 16y ago

Writing c++ is painful without IDE as well. Come to think about it, the same can be said about Objective-C

kenjackson 16y ago
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.
- __david__ 16y ago
  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.
  - kenjackson 16y ago
    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.
    - __david__ 16y ago
      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.
      - kenjackson 16y ago
        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).
        Roboprog 16y ago
        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.
    - Roboprog 16y ago
      >> 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.