How could you disable a .cpp file?
-
wrote on 26 Nov 2011, 05:06 last edited by
I think using macros more preferred
@//#define USE_FILE_NAME
#ifdef USE_FILE_NAME
...
#endif
@ -
wrote on 26 Nov 2011, 06:16 last edited by
[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.
-
wrote on 28 Nov 2011, 16:19 last edited by
[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...
-
wrote on 28 Nov 2011, 16:32 last edited by
[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?
-
wrote on 28 Nov 2011, 16:35 last edited by
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).
-
wrote on 28 Nov 2011, 16:47 last edited by
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. -
wrote on 28 Nov 2011, 17:09 last edited by
[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.
-
wrote on 28 Nov 2011, 17:23 last edited by
[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? -
wrote on 28 Nov 2011, 17:33 last edited by
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. -
wrote on 28 Nov 2011, 18:52 last edited by
Volker,
Commenting of course! As you said, cutting of the file from .pro (or using macros) are the best solution.
-
wrote on 29 Nov 2011, 07:02 last edited by
If you are used to svn then mercurial will be simpler to learn, since it has the same version numbering (aside the SHA1) and the concept of commit-a-single-file.
-
wrote on 29 Nov 2011, 07:26 last edited by
Instead of #ifdef.. something that makes more sense to me is:
#if 0
...
#endifBetter than /* ... */ because you can nest them.
-
wrote on 29 Nov 2011, 07:45 last edited by
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.
13/16