|
necrobobsledder posted:If you're doing an Agile development model, you'll be checking in code so often you'll probably hit a point where you'll just check it in and fix it up in another commit happening in only a matter of hours while you work on it. It's always weird to read things like these, go "WTF?", and then remember how most people still use revision control systems.
|
# ? Sep 12, 2009 00:42 |
|
|
# ? May 28, 2024 16:10 |
|
shrughes posted:It's always weird to read things like these, go "WTF?", and then remember how most people still use revision control systems. Maybe setting myself up for embarrassment, but can you explain how people should use revision control systems?
|
# ? Sep 12, 2009 01:04 |
|
geetee posted:Maybe setting myself up for embarrassment, but can you explain how people should use revision control systems? Don't check in commented out code because you're half done with it. Check in only code that builds. When you pick up your code tomorrow, use the handy conflict resolution tools that your RCS has! That way, you can see any changes that anyone made to things that your code might have been affected by, and people don't open up a method and go "WTF?" because there's a big block of half-done code in there and they have no idea how to go about modifying the code anymore.
|
# ? Sep 12, 2009 01:34 |
|
Ryouga Inverse posted:Don't check in commented out code because you're half done with it. Check in only code that builds. Fun way to stop people from checking in code that breaks the build: set up your VCS to notify a build machine every time someone checks in changes. Have your thankless robot build the project on every commit. When the build fails, your robot fires off an email to everyone: THE loving PROJECT DOESN'T BUILD NOW YOU CAN THANK: <PERSON> BECAUSE OF HIS OR HER CHECK-IN: <REVISION NUMBER> GO YELL AT THIS PERSON edit: doesn't stop simple human mistakes, but eventually people get the message and stop doing reckless poo poo Mikey-San fucked around with this message at 02:25 on Sep 12, 2009 |
# ? Sep 12, 2009 02:22 |
Mikey-San posted:Fun way to stop people from checking in code that breaks the build: set up your VCS to notify a build machine every time someone checks in changes. Have your thankless robot build the project on every commit. When the build fails, your robot fires off an email to everyone: quote:These 3 bears sit in a prominent position and watch our developer’s every move. When things are good we have a green bear gently glowing and purring, when changes are being processed a yellow bear joins the party, and if the build gets broken the growling evil red bear makes an appearance. The developer who broke things usually goes a similar shade of red while frantically trying to fix whatever was broken while the others chortle in the background. http://blog.last.fm/2008/08/01/quality-control
|
|
# ? Sep 12, 2009 02:25 |
|
shrughes posted:It's always weird to read things like these, go "WTF?", and then remember how most people still use revision control systems. Ledneh posted:I tend to agree with you, but as the guy who does a lot of the team's source control stuff, a message to my team: please god just use block comment constructs, I don't care if it's /* or #if 0, just don't use // everywhere If you're using Java at work though, you probably have bigger problems to fry than how code is block commented out... like fighting the deep-seated urge to make a noose out of your belt every day. Ryouga Inverse posted:Don't check in commented out code because you're half done with it. Check in only code that builds. fletcher posted:Three bear continuous integration system
|
# ? Sep 12, 2009 02:42 |
|
Janin posted:This applies to #if 0 ... #endif also Hrm, apparently you're right, at least in vi. I usually use #ifdef NEVER or some other such thing, which keeps syntax highlighting. Ryouga Inverse posted:Yeah, checking in commented out code is terrible. You're using source control for that reason, just take it out. Of course, for a more mature project with a larger team, there should be more stringent rules about checking poo poo in, and in those cases checking in commented out code is less reasonable.
|
# ? Sep 12, 2009 02:46 |
|
Ryouga Inverse posted:Don't check in commented out code because you're half done with it. Check in only code that builds. Oh! Yeah, that should go without saying Perhaps you'd like to meet some of my coworkers?
|
# ? Sep 12, 2009 03:11 |
|
Ryouga Inverse posted:Don't check in commented out code because you're half done with it. Check in only code that builds.
|
# ? Sep 12, 2009 03:55 |
|
Lysidas posted:Commented-out code doesn't affect whether the project builds Yes, I'm aware of that. Those were two separate and mutually independent statements; sorry that wasn't very obvious. Checking in commented out code is almost always bad. The problem is that if it stays there for more than about two commits, it's never going to leave, and then you have this problem where the rest of the codebase changes around this block of commented out code, and now it doesn't make any sense at all. I would have an example, but I'm not working at the company where I saw the most heinous example of this. Basically, it was a case of code reuse, where they took a previous project and then modified a few things. As stuff got modified, sometimes people would just comment out the old code, presumably so that one could see what it used to do. But then about five commits down the chain, that old code had nothing to do with what was actually going on anymore, but - surprise! - it was still there, and when I came in to look at the codebase, it made it far harder to understand what was supposed to be going on. I also had a coworker check in an entire file that didn't build for various reasons, but he had the genius idea to effectively comment it out by removing it from the project. That's why I said both of those things together
|
# ? Sep 12, 2009 04:32 |
|
geetee posted:Maybe setting myself up for embarrassment, but can you explain how people should use revision control systems? Well, reading things about "checking in code for the night" makes it sound like people are all working on the same branch or something... And having the timescale between "commits" being hours rather than minutes... :/ necrobobsledder posted:I was mostly saying that it's alright to check-in code that's commented out if you basically put a "under construction, here's what's shaky and don't step on these parts" sign up and if it's temporary. See, if it's under construction, it should just go in some private branch. Why don't you use a separate branch for every unit of change you're working on?
|
# ? Sep 12, 2009 15:53 |
|
shrughes posted:Well, reading things about "checking in code for the night" makes it sound like people are all working on the same branch or something... And having the timescale between "commits" being hours rather than minutes... :/ Do you really think it's useful to commit every few minutes?
|
# ? Sep 12, 2009 15:55 |
|
Athas posted:Do you really think it's useful to commit every few minutes? For some number of minutes less than sixty. And define "commit."
|
# ? Sep 12, 2009 15:58 |
|
Athas posted:Do you really think it's useful to commit every few minutes? I'd say that depends on compile times, I personally do a lot of micro-sized commits usually but then again I code Java and we have a CI which runs all the unit tests and builds the entire project after every single commit so (automated) error detection response time for us is usually somewhere around 3 minutes per project. That's partly why we don't even do any branching at our work, there just isn't need for it at our place.
|
# ? Sep 12, 2009 16:06 |
|
shrughes posted:See, if it's under construction, it should just go in some private branch. Why don't you use a separate branch for every unit of change you're working on? Not everyone uses a DVCS, sadly.
|
# ? Sep 12, 2009 23:54 |
|
Parantumaton posted:I'd say that depends on compile times, I personally do a lot of micro-sized commits usually but then again I code Java and we have a CI which runs all the unit tests and builds the entire project after every single commit so (automated) error detection response time for us is usually somewhere around 3 minutes per project. That's partly why we don't even do any branching at our work, there just isn't need for it at our place. What if something breaks in production when you're half way through developing a new feature?
|
# ? Sep 13, 2009 00:58 |
|
Sewer Adventure posted:What if something breaks in production when you're half way through developing a new feature? That's the only downside of our "system" at the moment. However when any of our production environmetns break it usually isn't due to the actual code but some related issue like out of memory, typos in templates, some external resource not available etc. I'd say it has happened only like twice or thrice during my time at the company (15 months and counting) when we had to temporarily roll back a feature, replace it with a production-specific fix, commit that, retag the fix, rebuild the software, deploy and then re-add the new/improved feature. Our chosen general solution for this problem is modularization of our systems with lots and lots of unit tests which has already proven to be a rather good choice for us: For example if Client A has bought from us Products 1 and 2, we create a new project for A which receives 1 and 2 through our own Ivy repository and then we just add client specific code to that project. Doing things this way has allowed us to separate our "critical" code bases with our client code bases so that if production environment breaks, the break is usually caused in the code that's in the client-specific portion and if it isn't, we can separately update the product code, update the Ivy dependency and roll out a new client specific deployment version. This may sound like dependency hell waiting to explode on our faces but in fact it won't since we use Ivy instead of Maven. Small addentum: One of the reasons we didn't go with branching was that at least Eclipse doesn't handle CVS branches in the most logical way and for some reason our Linux guys couldn't get it to work at all. But back to coding horrors, I guess.
|
# ? Sep 13, 2009 10:26 |
|
Parantumaton posted:I'd say it has happened only like twice or thrice during my time at the company (15 months and counting) when we had to temporarily roll back a feature, replace it with a production-specific fix, commit that, retag the fix, rebuild the software, deploy and then re-add the new/improved feature. When you say "roll back a feature" do you mean "roll back the current feature in progress" or "roll back all features since the release with the production bug"?
|
# ? Sep 13, 2009 10:50 |
|
floWenoL posted:When you say "roll back a feature" do you mean "roll back the current feature in progress" or "roll back all features since the release with the production bug"? Current feature in progress, our unit tests and modularity of systems allow us to rollback only the relevant parts.
|
# ? Sep 13, 2009 11:08 |
|
Parantumaton posted:Current feature in progress, our unit tests and modularity of systems allow us to rollback only the relevant parts. What I'm asking is that if you push out a production fix, do you also push out all completed features since the last release?
|
# ? Sep 13, 2009 11:11 |
|
floWenoL posted:What I'm asking is that if you push out a production fix, do you also push out all completed features since the last release? Depends, we can choose to do either.
|
# ? Sep 13, 2009 12:22 |
|
shrughes posted:See, if it's under construction, it should just go in some private branch. Why don't you use a separate branch for every unit of change you're working on? Oh, and as mentioned, not everyone has DVCS. Hell, we just moved to Subversion last week. For smaller teams with few dependencies per contributor in the first place and everyone doing work at work really, DVCS is not of much use for us.
|
# ? Sep 13, 2009 18:44 |
|
Edit: Decided against having this here.
Sebbe fucked around with this message at 22:44 on Sep 13, 2009 |
# ? Sep 13, 2009 20:22 |
|
I like ponies
Athas fucked around with this message at 06:31 on Sep 14, 2009 |
# ? Sep 13, 2009 20:51 |
|
Is that a programming competition or something? High schoolers trying to program produces some real horrors, like the team that had to print "One Two Three ... Nine Hundred And Ninety Nine" and decided a massive for-switch loop would be appropriate, for every single number. It took them all day and it still didn't pass. That year, as the only person actually programming on my team, we came in first place against other teams of three, beating second place by 50% on score. I suck at programming now and I sucked more then, too.
|
# ? Sep 14, 2009 03:14 |
|
ryanmfw posted:Is that a programming competition or something? High schoolers trying to program produces some real horrors, like the team that had to print "One Two Three ... Nine Hundred And Ninety Nine" and decided a massive for-switch loop would be appropriate, for every single number. It took them all day and it still didn't pass. That year, as the only person actually programming on my team, we came in first place against other teams of three, beating second place by 50% on score. I suck at programming now and I sucked more then, too. This is why I'm so glad I managed to find my current job, working with a small team of highly skilled programmers on a very complex project, in C, with git. There's such a learning curve, the 95% of incompetent programmers, who somehow managed to get honors degrees in Computer Science but think Strings are acceptable substitutes for booleans, will never get in. It's perfect.
|
# ? Sep 14, 2009 16:35 |
|
ColdPie posted:This is why I'm so glad I managed to find my current job, working with a small team of highly skilled programmers on a very complex project, in C, with git. There's such a learning curve, the 95% of incompetent programmers, who somehow managed to get honors degrees in Computer Science but think Strings are acceptable substitutes for booleans, will never get in. It's perfect. Are you the other 5%?
|
# ? Sep 14, 2009 18:25 |
|
Avenging Dentist posted:Are you the other 5%? Don't you know that everybody thinks they're in the top 5%? Edit: Oh wait I see the burn now. Good show, sir.
|
# ? Sep 14, 2009 21:24 |
|
Avenging Dentist posted:Are you the other 5%? Fuuuuuuuuuuuuuuuuuuuuuuuuck
|
# ? Sep 15, 2009 05:46 |
|
I don't know if this has been mentioned yet, but I just found out that according to the C standard, a[i] and i[a] are equivalent. This function: code:
Having never entered any obfuscated C contests, I was unaware of this. edit: code:
mr_jim fucked around with this message at 01:30 on Sep 18, 2009 |
# ? Sep 18, 2009 01:11 |
|
mr_jim posted:I don't know if this has been mentioned yet, but I just found out that according to the C standard, a[i] and i[a] are equivalent.
|
# ? Sep 18, 2009 03:53 |
|
quote:The Committee found no reason to disallow the symmetry that permits a[i] to be written as i[a]. From the "Rationale for ANSI C" (http://www.lysator.liu.se/c/rat/c3.html#3-3-2-1) Personally, I don't see any reason for array subscripting to be commutative. But I wasn't on the committee.
|
# ? Sep 18, 2009 04:28 |
|
necrobobsledder posted:Maybe it was to compete for Fortran users or something? code:
|
# ? Sep 18, 2009 04:39 |
|
Dijkstracula posted:Fortran's array indexing, barring specifying index ranges, isn't that different than C's. You certainly can't do i[a] in Fortran, so I don't know what you mean.
|
# ? Sep 18, 2009 05:51 |
|
Guys, the a[i] / i[a] equivalence is just because the standard defines a[i] as being equivalent to *(a+i).
|
# ? Sep 18, 2009 06:08 |
|
I coulda swore "offset[index]" was simply treated as referencing the address at "offset + index*element_size". So the trick only worked for data types the compiler was rounding off to whatever the platform was using for a byte. After messing around on codepad it seems to handle any data type just fine.
|
# ? Sep 18, 2009 07:20 |
|
Bhaal posted:I coulda swore "offset[index]" was simply treated as referencing the address at "offset + index*element_size". So the trick only worked for data types the compiler was rounding off to whatever the platform was using for a byte. What C data type (other than bitfields) are addressed in units smaller than a byte?
|
# ? Sep 18, 2009 10:01 |
|
floWenoL posted:What C data type (other than bitfields) are addressed in units smaller than a byte?
|
# ? Sep 18, 2009 11:23 |
|
Avenging Dentist posted:Guys, the a[i] / i[a] equivalence is just because the standard defines a[i] as being equivalent to *(a+i). I understand why they're equivalent. But I also think one could make a case for disallowing that particular syntax, even though it would make writing a compiler slightly more complex. Then again, I doubt "i[a]" ever gets used in real code, so what the harm?
|
# ? Sep 18, 2009 12:28 |
|
|
# ? May 28, 2024 16:10 |
|
3. "Just makin' sure."code:
code:
code:
|
# ? Sep 18, 2009 13:56 |