Timeline for Is committing/checking in code everyday a good practice?
Current License: CC BY-SA 3.0
9 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 9, 2012 at 4:25 | comment | added | Giorgio | "I don't leave a document in an unfinished state at the end of the day - I'll make sure it's coherent and a readable 'draft'.": If the content is not too complex, yes, this is feasible: I have nothing against it and I do it as well. | |
| Jul 9, 2012 at 2:52 | comment | added | Kirk Broadhurst | I don't leave a document in an unfinished state at the end of the day - I'll make sure it's coherent and a readable 'draft'. Similarly, I won't go home mid-function if I'm coding. Another benefit of checking in every day is that it forces you to tie up the loose ends in your code, so that when you arrive next morning you have a logical start point. | |
| Jul 9, 2012 at 2:22 | comment | added | Giorgio | I have the impression we are running on two parallel lanes. My point is not whether I should check in or not, but when. I would not check in something I still consider unfinished and not yet worth testing or reviewing. Take the analogous situation that you are writing some document. Do you want people to read a document containing half-finished sentences or paragraphs, incomplete or unclear ideas? No. You normally give them something that, while being a draft, you consider worth reading otherwise you are wasting their time (and yours). | |
| Jul 9, 2012 at 1:31 | comment | added | Kirk Broadhurst | @Giorgio do you not have a development branch that you are checking into? The code should be checked in so that other people can review and test it as well. | |
| Jul 9, 2012 at 1:20 | comment | added | Giorgio | This is not always possible, e.g. if I am developing from scratch some complex code (> 4000 LOC) which needs a lot of experimentation to get right. It is well possible that at the end of the day the code is a bit messy and I don't want to fix it until I get to a consistent state, which is a couple of days later. Unfortunately I am not so smart that finished, perfect code forms in my mind and I can always have it all written down in a few hours (i.e. at the end of one day). I had such an experience lately and the typical development cycle (from one consistent state to the next) was 2, 3 days. | |
| Jul 8, 2012 at 22:56 | comment | added | Kirk Broadhurst | @Giorgio So you spend several days cleaning up your code? I've given some good reasons for checking in daily - your reason is that you will have to clean up your code? Just write cleaner code straight up. | |
| Jul 6, 2012 at 10:04 | comment | added | Giorgio | I understand your point that one should not be lazy and clean up their code every day so that it can be checked in. On the other hand, when working on some complex code, this is difficult to achieve because the clean up may take several hours, and you cannot spend several hours every day only to clean up your code. | |
| Jul 6, 2012 at 9:57 | comment | added | Giorgio | "I don't believe there's any good reason to check in less than daily apart from laziness or disorganisation. ": I believe the opposite for exactly the same reason. I can take the time to look at the current state of the code and decide if it contains some relevant information that is worth remembering, or, if I am lazy and disorganized, I can simply check it in (and produce extra revisions with little information content) as long as it compiles. | |
| Jul 6, 2012 at 5:58 | history | answered | Kirk Broadhurst | CC BY-SA 3.0 |