Using IFDEF to comment blocks in Elements 10?

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)?

You could just use {, (* or /* to comment it out? IFDEF still works but it does expect syntactically valid code.

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

Thanks for the tip

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. :wink:

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 ?

Cmd-/ or Ctrl+/ respectively, and it works awesomely :wink:

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/

1 Like

more immediateā€¦and probably comforting :o/

This.

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.

imho. ymmv. :slight_smile:

Weā€™ll make a special compiler mode for you that does not support comments :stuck_out_tongue_winking_eye:

LOL

Actually, in all seriousness, a compiler/code analysis tool which recognises and flags commented out code with a warning/hint might actually be useful. :thinking:

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 ? :wink:

where to draw the line between ā€œinvalidā€ commented out code and real comments though?

contrived sample:

//for each item in list do something:

is this a valid comment text, or is it code? ;p

Neither. Itā€™s not code but itā€™s not a valid comment either. :slight_smile:

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. :slight_smile:

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. :slight_smile:

1 Like

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.

-John W.

Nah, itā€™s fine, the issue needed clarification in any case.

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. :slight_smile:

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).