1

I was working in a story and in last minute, I have been asked to hide something from UI and we will used it next release.

  • Should i remove it or comment it

  • Should i remove or comment anything related to this part from code or leave it if it won't effect in anything.

|improve this question
  • Possible duplicate of Dealing with code that has been written but isn't yet needed – gnat May 24 '17 at 11:46
  • No, different case .. i need to hide something from UI for this release until it refined again. so i should remove it or comment it and i should remove all backend code related to it. (this is my question) – Ahmed Ragheb May 24 '17 at 12:07
  • Is this working code with tests, or just the start of a feature? – Erik Eidt May 24 '17 at 17:47
11

If you value clean work practices, I would suggest that instead of commenting out code (which is an OK enough practice in the very short term, i.e. when we're talking a few weeks or less), prefer to use a source control system (Git, Mercurial, Subversion, etc.) instead:

Move the feature's code, and all that's specifically related to it and not used by other code, to a separate feature branch (i.e. a fork off your current development branch). Make sure the code is completely removed in the main development branch. That way, all you will have to do to reactivate the feature is to merge the feature branch back into the main development branch. What you will not have to do is undoing the commenting-out on a line-by-line basis (running the chance that you forget to uncomment something, somewhere).

It might be a little bit more work, but a much cleaner work practice than commenting out code. Commented-out code has the habit of accumulating over time, and it's often never uncommented again (against previous expectations). For that reason, unless a piece of commented-out code has explicit documentation stating why it's commented out, and when it should be uncommented again, I tend to purge commented-out code from a code base whenever I stumble upon it.

For the same reason, I would suggest that you don't only disable/remove the "triggering" code of a feature, but all other code that is also related to only it (even if it would never have any effect if you removed the core feature code). Because, if you eventually don't put the feature in the next release, you might forget about the dependent code. So treat it the same was as the "core" / triggering feature code.

|improve this answer
  • But this is candidate branch and we will go production soon, Do you think removing code from Front-end, back-end, Models and after that fix unit testing .. is a good idea ? – Ahmed Ragheb May 24 '17 at 9:40
  • 5
    If I thought it was a bad idea, I wouldn't have written a whole answer suggesting it. ;-) But like I wrote, it is a little bit of work, so it probably does depend on the time frame. If your next release is in only two weeks, or at the very least you are very, VERY sure that the feature WILL make it into the next version soon and you won't forget how to properly reactivate it until then, you're probably better off with commenting out code. Otherwise, you want some documentation of the needed edit history, and IMO a source control feature branch would be the safest & cleanest option here. – stakx May 24 '17 at 9:58
  • 1
    @AhmedRagheb Just wanted to add something. If any work is done at all, it is best to not throw it away. Keep it in a separate branch, even a separate file. But don't throw away the work that is already completed. – jitendragarg May 24 '17 at 15:25
4

Here's what I would do:

  • Before you do anything, we make sure your code is checked in to source control. That way, you can always recover it later if you need to.

  • The general rule is that you should remove code that you don't need any more, to keep the codebase as clean as possible. So, if you don't expect your code to be re-used in the 'near future', remove it.

  • However, in this case, there is good reason to expect your code to be used in the next release. So, commenting it out (with a comment to explain what you're doing) is probably your best bet. If you discover that you don't use it after all, you (or your successor) can remove it later.

|improve this answer
4

Alternatively, if your code is self-contained and this measure is temporary, you may get away by wrapping the code inside an if statement and set a boolean flag to disable the code block. Whether this is good practice though...

|improve this answer
  • 3
    Yep. An 'if' statement reading a line from a configuration file parsed as a boolean and you're not only done now, but when its time to re-enable the feature, you just change one value in the config file. This is called "feature toggling" and is so simple compared to the various branching strategies listed above that many folks will immediately disregard it. I would have typed this exact answer had it not been posted here first. – Graham Sep 5 '18 at 19:36
2

If you use version control such as SVN, Git or Mercurial you can put it on another branch and remove it from the release/main branch. You can merge the branch to the release branch when it's ready for release.

If you do not use version control, it's okay to put it in comments. However, when you put something in comments it's easy to forget about it, so I would advise to start using version control if you don't do that already.

|improve this answer
  • i use source control and what about second point ? – Ahmed Ragheb May 24 '17 at 9:24
  • 10
    "if you do not use version control" your code doesn't exist! – jonrsharpe May 24 '17 at 9:28
  • 2
    @AhmedRagheb Same, just put it on the other branch. – PJvG May 24 '17 at 9:29
  • 1
    If you do not use version control, start using version control. – JeremyP May 24 '17 at 9:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.