These (maintaining a clean codebase, using source control, branching) are good practices for solo developers as much as anyone else.
> El ene. 15, 2017, a las 2:24 PM, Amir Michail via swift-evolution > <[email protected]> escribió: > > >> On Jan 14, 2017, at 8:11 PM, Jay Abbott <[email protected]> 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 >>> <[email protected]> wrote: >>> >>> On Jan 14, 2017, at 6:56 PM, Xiaodi Wu <[email protected]> wrote: >>> >>> >>> >>>> On Sat, Jan 14, 2017 at 5:50 PM, Amir Michail <[email protected]> wrote: >>>> >>>> On Jan 14, 2017, at 6:46 PM, Xiaodi Wu <[email protected]> wrote: >>>> >>>> On Sat, Jan 14, 2017 at 5:35 PM, Amir Michail <[email protected]> wrote: >>>> >>>>> On Jan 14, 2017, at 6:28 PM, Xiaodi Wu <[email protected]> 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 >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
