Whilst I can see some other threads relating to type based IFDEF use, none appear to tackle my new concern.
I have long used
{$IFDEF FALSE}
Some old nonsense
{$ENDIF}
to comment out long (often really long) chunks of redundant code.
Do the new changes to Elements 10 prevent me from doing this now? Or is there an alternative way to do the same (without using editor hacks to add // globally)?
Iāve always been wary of /* */ in case there were shorter multi-line nested comments, that scuppered that logic. Similarly with { comment block }.
As I wasnāt aware of (* being an option, I will perhaps have to switch to that and avoid these outer most chunks being double-bagged, a secondary, but probably less onerous problem
Commenting out old code is an anti-pattern. If there is old code you donāt want/need any more, remove it.
Unless you arenāt using a change repository (git/svn/etc). But that too is an anti-pattern on an epic scale.
If the commenting out is temporary (e.g. while refactoring) then just use the comment tool on the block of code, which will add a line comment to every line which can then be removed by re-selecting the block (or just some sub-range) and using the uncomment tool, which will remove a line comment from each line.
Comment/Uncomment both add/remove a single line-comment token (//) at a time.
i.e. comment +> comment +> uncomment = still commented [x1]
Because it uses line comments, it works even if the block you are commenting out already includes comments of any sort since it does not rely on block commenting and thus is not vulnerable to interactions between different/nested block comment styles.
NOTE: The above assumes youāre using Visual Studio. I donāt know if Fire/Water support comment/uncomment in the same way ?
Long term block commenting, I would agree is pretty futile, although I still hold store with short term historic comment blocks remaining after significant re-factoring.
It serves as both an exercise in self documenting history, whilst also giving an alternative way to reverse engineer changes that donāt quite work out as you hoped.
SVN is fine for most cases (of reflection), but the comment block still feels more immediateā¦and probably comforting :o/
You wonāt appreciate why embracing that immediacy and comfort is so misplaced until you have reached a critical mass of dead code which results in drag every time you update the code it (appears) related to and have to spend time trying to remember why you commented it out, what it did, why it was no longer needed and why you felt you needed to keep it hanging around.
As much as you think you can embellish the commented out code with a commented aide memoir to your future self to avoid that, you will not get it right because you are writing that memoire now when you donāt know what you will have forgotten in the future. And when you update the code that is not commented out, how often do you go back and reflect on the continued relevance of the commented out code and update accordingly ? Answer: (In my experience of numerous code bases) Never, or at least not as often as you should (even if you think you always do/will).
So 99% of the time you will decide that instead of wasting time trying to understand that dead code/useless memoir, you will instead simply ignore it and focus on the code that really matters - the stuff that actually does do something and isnāt commented out. i.e. you could (and should) have just removed that commented out, dead code in the first place.
As I said - commenting out code is an anti-pattern. Something we do because we think itās helpful but really it isnāt.
Actually, in all seriousness, a compiler/code analysis tool which recognises and flags commented out code with a warning/hint might actually be useful.
We have hints/warnings about variables that are declared but not used which I think most people would agree is A Good Thing. And what is commented code if not code that is - by definition - not being used ?
Neither. Itās not code but itās not a valid comment either.
By which I mean it doesnāt explain why the code is doing what it does (or doesnāt do things you might otherwise/normally expect it to do), it simply restates what the code already does.
Some contrived āgoodā (imho) comments:
// Get a list of customer orders ensuring that we are not working
// with an IQueryable because we will need to iterate this list multiple times
var orders := CustomerOrders.GetOrders( custId ).ToList();
// We need the total value of all orders before we do any further processing
var totalValue: Currency := 0.0;
foreach var order in orders do
begin
totalValue := totalValue + order.Value;
end;
Sure, but I donāt think weāll wanna add critique on that to the compiler. Point is, itās valid English prose, but also indistinguishable from code. I donāt see how the compiler could reasonably and reliably be expected to distinguish one from the other, in comments.
Ah I see. Yes. I didnāt say it was easy or even do-able. I just observed that it might be useful.
But sometimes even contemplating/considering the improbable/impossible casts a different light on the possible and reveals dark corners of the possible that were previously not seen.
In your contrived case yes it might reveal a āfalse positiveā, just as sometimes a hint/warning is some edge case that a bit of syntactic chicanery is required to avoid. In this case, if the comment were to result in a āCommented codeā warning, the solution - or part of it - would be to rephrase/re-punctuate to make it recognisably not codeā¦
After all, if the compiler thinks it is commented out code then a human might also think that, and the point is to make sure that our comments are useful. If a human or a machine cannot tell the difference between a comment and commented out code then this perhaps still points to a defect in the āqualityā of the comment. No ?
But this is getting a bit philosophical and dangerously OT.
Oof - Iāve kicked off a right sh!t-storm with this one.
Itās fair to say my hasty upgrade to Elements 10 has laid bare my previously errant ways which, post rewind, I have already begun to correct across my Oxygene code base.
Feel sure Iām taking a good hard look at myself, as I prepare for my next attempt ;o)
Agreed 100%, and which (again) nicely brings us back to ācommenting out code is an ANTI-patternā.
The solution in such a case is to flag it, because it isnāt really a āfalse positiveā, technically, if it really could be parsed as code (and thus also likely to be mistaken as code by an observer in future lacking a priori understanding of how comment came into existence). The dev has the choice to circumvent or fix, but itās still worth flagging because there is still a real, foreseeable risk in its existence.
Absolutely not. An engaged and interesting discussion, even one involving an exchange of views and/or sharing of opinion is not a sh!tstorm. Weāre a long way from that yet.
Weāre not even in āfrank exchange of viewsā territory yet.
Everything can be PARSED as (broken() code. All former joking aside, weāre not going to complicate the compile(r) by making it have to guess āhow closeā commented out prose it to good or bad code. Often times, commented out code is commented out because it is broken. Where do you draw the line between ābroken enough to tease out as prose (in any language known to man, not necessarily englishā on one side and āonly. little broken so it could be commented-out codeā).
And thatās fine, no-one forces you do practice it. But you cannot rely on the compiler to tell you, because, by very definition, commenting out code tells the compiler ānevermind this bit, whatever it may beā.
Just returned to Elements 10 after a long gap (and having removed all traces of previously problematic {$IFDEF FALSE}), but Iām still finding this new compiler an absolute nightmare. Code that has been compiling perfectly will with pre-10 has suddenly gone into meltdown with several hundreds of compiler errors.
Whilst I donāt doubt that some of those are as a result of sloppy practices that have been tolerated up until now, Iām seeing quite a sizable swathe that are simply down to things like how the IDE has implemented the āComplete Classā command i.e. implementing it with a slightly re-structured interface.
Many of these are relatively easy to figure out, but some Iām struggling to find the correct alternative. What for example do i do withā¦
Attributes of type āSerializableAttributeā cannot be applied multiple times on the same
Attributes of type āDataContractAttributeā cannot be applied multiple times on the same
Iāve got to say, Iām getting to the stage of rewinding back to v9 again, despite that ultimately leaving me in no mans land.
Have you any words of advise or tips to soften this transition? Whilst Iām curious by āWaterā and your other initiatives, which I assume are behind most of these transformations, I am not even close to doing any cross platform work. Iām simply trying to keep my existing ASP.NET code base on track
It kind of depends on the structure of your existing code.
You can revert to the old behavior in the v10 compiler with <UseLegacyPreprocessor>True</UseLegacyPreprocessor> so you should at least be able to keep things working in there.
If you can show an example of a code fragment that fails in v10, I can offer suggestions or fix it in the compiler (depending on the code).