How could you disable a .cpp file?
-
[quote author="Flurite" date="1322255621"]Is there anyway to disable a file? I want to keep the code there for future reference, but I don't want it to run, so is there a way to disable the script, or should I just comment everything out?
Thanks,
Flurite[/quote]You can achieve this: you can use a #ifdef macros to ignore it; to exclude it from the pro file or the comment it.
-
[quote author="Flurite" date="1322265432"]Okay, thanks, I think I'll stick with commenting it. ;)[/quote]
Honestly this is the worst solution. It would be better to use a macros.
-
[quote author="leon.anavi" date="1322288172"]
[quote author="Flurite" date="1322265432"]Okay, thanks, I think I'll stick with commenting it. ;)[/quote]Honestly this is the worst solution. It would be better to use a macros.
[/quote]
Besides valid, this should not be consider an option at all...
-
[quote author="fguimaraes" date="1322497184"][quote author="leon.anavi" date="1322288172"]
[quote author="Flurite" date="1322265432"]Okay, thanks, I think I'll stick with commenting it. ;)[/quote]Honestly this is the worst solution. It would be better to use a macros.
[/quote]
Besides valid, this should not be consider an option at all...[/quote]
Do you refer to commenting or to using macros?
-
Why not placing a file into a versioning system, and then deleting it until it comes again needed? In this way your code base will be clean (not listing unused files) and you will be able to get it back in the future. I believe it is simpler to not read a file at all than read it and realize it is not used (speaking for the human being part).
-
If you are using an IDE, you might have the possibility to exclude it from compilation (e.g. in Visual Studio). In qt creator you may throw it out from your definition file, but there might be different ways as well.
The macro and commenting options are certainly valid and I agree with the other responses. Personally I would limit it to section within a file. Commenting for shorter sections and macro for longer.
However, as you like to exclude a complete file. Why aren't you moving it to subfolder "unused" for example. You may still maintain it in a source management system, but it will be also absolute clear that you are not using at the time. Otherwise it will be come a bit messy with several files not used in the application. -
[quote author="koahnig" date="1322498832"]Why aren't you moving it to subfolder "unused" for example. You may still maintain it in a source management system, but it will be also absolute clear that you are not using at the time. Otherwise it will be come a bit messy with several files not used in the application. [/quote]
My opinion is that this is a CVS-attic like solution, and you will easy get your project messed up since you will loose any information about when, from where and why the file has been moved. I strongly suggest using a good versioning tool.
-
[quote author="fluca1978" date="1322500186"]
My opinion is that this is a CVS-attic like solution, and you will easy get your project messed up since you will loose any information about when, from where and why the file has been moved. I strongly suggest using a good versioning tool.
[/quote]
I am using subversion. So no wonder that this might be CVS-attic.
Which versioning tool would you recommend? -
I personally prefere to exclude it from the list of files to compile in the project setup (.pro file, visual studio project solution, XCode...) and keep it in the sources.
@koahnig
State of the art version control systems are distributed - you benefit from that even as a single developer. The most popular in that domain are "Mercurial":http://mercurial.selenic.com/ (hg), "GIT":http://git-scm.com/ (git) and "Bazaar":http://bazaar.canonical.com/ (bzr). I personally prefer hg, Qt uses git. The principles and features are quite similar, there are some subtle differences, though. You'll have to make your own decision matrix. IIRC there have been some threads on that topic in the forums, better continue discussion there or open a new thread. -
Volker,
Commenting of course! As you said, cutting of the file from .pro (or using macros) are the best solution.
-
Instead of #ifdef.. something that makes more sense to me is:
#if 0
...
#endifBetter than /* ... */ because you can nest them.
-
I've never seen code that used macros (#if 0 and alike) or multiline comments to disable large sections of code which wasn't just pure pain to read and understand, especially during code review sessions. It gets even worse if your are forced to use an editor which doesn't support visual suppression of disabled code.
It might have its right during immediate development, but every coding guideline should strictly enforce that all disabled code has to be removed as soon as a file is commited. If it needs to be archived a versioning system is the way to go.