[swift-evolution] Code comments that check code validity.

[Amir Michail]

> On Jan 14, 2017, at 8:11 PM, Jay Abbott <jay at abbott.me.uk> wrote:
> 
> I think this would be an anti-feature , here are some reasons why:
> 
> 	• If it is code you wrote as an idea for how something might be implemented in the future, then it should be manually tweaked/validated anyway when you put it back in. If things change slightly such that your old commented code breaks when you comment it back in this is a good thing, it forces you to check/amend the old code so that it functions properly in the updated environment that it now inhabits.
> 	• If it’s a significant amount of code then it really ought to be structured into something appropriate, like a function or a class, in which case it can happily live uncalled and not commented out. But it’s not a great practice to leave unused code lying around, unless you know it’s going to be used soon.
> 	• Commented code is often commented out specifically to make things compile while you tweak/break things somewhere else (i.e. commented out temporarily) - so of course you don’t want it to be compiled.
> 	• If you comment out code temporarily then it really should just mean temporarily, i.e. between now and your next commit to test something immediately. Source control means there’s no need for longer-lived commented out code. Unfinished code can live on a branch, old code that you might want to refer to or re-use later is in your source control history, and unused code should probably just be removed.

Other developers may prefer to have some code comments. Solo indie developers have more freedom to just do what they want in this respect...

> 	• Code that is written and working and intended to be enabled later on should be activated by a feature-toggle (either a compile-time or a run-time one) rather than commented out.
> 
> On Sun, 15 Jan 2017 at 00:04 Amir Michail via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> On Jan 14, 2017, at 6:56 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>> 
>> 
>> 
>> On Sat, Jan 14, 2017 at 5:50 PM, Amir Michail <a.michail at me.com> wrote:
>> 
>>> On Jan 14, 2017, at 6:46 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>>> 
>>> On Sat, Jan 14, 2017 at 5:35 PM, Amir Michail <a.michail at me.com> wrote:
>>> 
>>> > On Jan 14, 2017, at 6:28 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>>> >
>>> > This has been brought up on this list before. The conclusion of the previous thread on this topic was that there is a way to do this:
>>> >
>>> > #if false
>>> > // put your code here
>>> > #endif
>>> >
>>> 
>>> This would not check the code for compilability within the surrounding code. This requires more than a syntax check.
>>> 
>>> I can't say I've ever needed that feature; could you share a concrete use case?
>>> 
>> 
>> Consider an array of levels for a game where some levels are commented out for possible future use. It would be nice to have such level entries continue to compile as the code elsewhere evolves and yet not be included in the executable.
>> 
>> ```
>> enum Levels: Int {
>>   case foo = 1, bar, baz, boo
>> }
>> 
>> var levels: [Levels] = [
>>   .foo,
>>   .bar,
>> ]
>> 
>> // disabled
>> _ = {
>>   levels += [
>>     .baz,
>>     .boo,
>>     // this won't compile if you add:
>>     // .nonExistent,
>>   ]
>> }
>> ```
> 
> That’s helpful thanks! I still think code comments would be nice though.
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution