Tag Info

New answers tagged

3

When I use TODOs (and FIXMEs), I tend to write them as questions, rather than statements. For example: // TODO: Can we ignore the negative case? // TODO: Is this premature optimisation? // FIXME: Is there a more robust alternative to parsing the version number? // TODO: Is it worth extracting this to a separate module? There are a few reasons for this: ...


-1

In anycase I am not sure what to replace my TODOs. It frustrates me that when I see faulty or questionable code i cannot add a marker. It sounds like: You know of a limitation in your code. You do not have time to address it now. You need to check in your code now. You need to document that limitation so it can be addressed in the future. That ...


-1

You should never put rules on what should not be checked in. The day a PC trashes it's hard disk containing hours/days of coding that is not checked in for some obscure reason will be the day you change the rule. I will even check in code with syntax errors or code that just won't run (rarely but not never).


4

I'm very sceptical about TODOs. I think all too often they serve as a label that helps to pass procrastination as some sort of a disciplined approach. Therefore I'm inclined to side with your team and I'd advocate to refrain from using them other than solely for private use, which is nobody's business of course. It's all good and well in theory, but as ...


0

We find that the main reason people want a "todo" on a feature completed piece of code is to express an idea or future improvement to be made at some point in the future. The unfortunately consequence of this is that the todo explorer for many developers is used for active and in progress code. To overcome this we add XML comments above methods and classes ...


11

To begin with “TODO” seems great... Then people starts to check code in with them. Then after a few years, the checked in code has 1000s of “TODO” in it. At that point, they become worthless, as you can’t use a TODO to track own work in process in any code. Hence the common rule about not checking in TODOs into branches that are meant to contain ...


25

I think this discussion pivots around a few things, not solely on the TODOs in the comments of the code - but they how are used and what they are used for to begin with. Code checkins If you are using private working branches, then checking in code that has odd temporary comments and markers as personal pointers of your own thoughts may not be so bad ...


2

Can you recall a situation where a good commit message saved you at least 3 hours? Yes, absolutely I can! Properly written commit message will have keywords of major changes to the system. SO you could glance on it and know exactly that's the commit you need. We once had a defect that was originating from changes(we have 24 people team, so good luck ...


3

Ask for meaningful commit messages The problem does not come from using merge commits instead of rebase in this particular case. It is the lack of meaningful commit messages. For example, without seeing your repository, this could very well be a merge commit: Ron Cosby PROJ-15711: Fix the jsdoc template But contrary to the other commits, this one ...


1

One way of 'hiding' the merge change sets is to use Mercurial Queues. It is an extension currently being distributed along with Mercurial. In short, they are mutable change sets, known as patches in a patch-queue. Instead of having to merge, your users can rebase and then apply the patch or patches they want to push on top of the tip of the rebase, ...


9

Since the history is preserved in version control, there is absolutely no reason not to remove code you don't need. By the way, this applies as well to commented code within the source: don't comment blocks of code, just remove them; if you'll need them later, version control is your friend. Later may be even in an hour. The common sense may dictate that if ...


4

The problem with deleting is that they are "out of sight" and therefore "out of mind". The problem with archiving is that links or relative references will no longer apply. Tricky... Personally I would delete them, and tag the revisions that these were deleted. This allows the dead projects to be easily retrieved, in place, yet also be hidden but still ...


1

One (common) way of solving your problem is with the use of branches, as described by the other answers. However, there is another solution: feature toggles (aka. feature flags). The basic idea is that your program maintains a list of flags (the feature flags) that can be switched on and off, and the code that implements the feature checks its ...


4

Each branch has a role. Branching for a feature is a good one as it allows the feature branch to specifically identify that role. Always merging back to default implies that default is the roles of mainline, accumulation, and packaging - and this is where you are having trouble. You should instead consider making a branch for the role of 'accumulation for ...


3

I think that your workflow of writing a feature (or a bug fix) and then committing it to the "default" (which appears to be a main or trunk branch) is the problem. Instead, consider using an alternative branching strategy. I'm typically only focusing on one release at a time, so there's an "integration" branch off of the trunk and then there are development ...


5

If your systems are sufficiently modular and link compatible, you would benefit from a single repository and build. For example, if C system is being rewritten in C++, the C++ code could call existing functionality and incrementally replace it. However, even in this case some might argue for starting a new repo in which relevant old code is pulled in as ...


44

You almost certainly want a new repository. The purpose of the repository is: to track history and changes so you can compare them easily to manage branches and merges rather than just emailing patch files around and applying them to working directories manually If you're totally rewriting a project from scratch then there is no point putting the ...


16

I always put rewrites in new repositories myself. That way the builds, tests, and deployments can all be done independently. When you're rewriting a project in another language there's often very little similarity in any of those tasks like building, running tests, and deploying. You'll save yourself pain if you just isolate them in their own repository. ...



Top 50 recent answers are included