Hello, I'm one of the devs working on ABL. Nothing is set in stone yet but we're looking into implementing single line comments. Anyway, here are some issues we'd like your feedback on.
In an ideal world, we would use // as the starting delimiter for line comments. However, this clashes with statements like:
OS-DELETE C://tmp/tmp.txt.
RUN //rdlserv/cdimage/foo.p. /* This is a UNC path */
A few other statements that possibly use // as valid syntax are most of the OS-* statements, INPUT, OUTPUT, RUN, SYSTEM-DIALOG GET-DIR/FILE, and COMPILE.
How would you guys feel if single line syntax was //<whitespace>? This would allow it to be differentiated from paths and wouldn't be too different from industry standard. On the other hand, it's a bit more tedious and it's pretty easy to forget that a space is required, especially if you have a background in languages like Java, PHP, or C++.
Another solution is to use different characters for single line comments. One of our most favorable alternative syntax is two semi-colons (;;). # is unfortunately out of the question since we allow that character in variable names. Using different characters removes the whitespace requirement but will vary differently from what's typical in other languages.
The last solution is to implement // without whitespace. This will cause behaviour changes that might break statements where a path is hardcoded with double slashes and without quoting the path. However, it'll be the simplest and most expected form of single line comments. Discussion here in HQ asserts that the number of people whose code will be broken with this change is very, very small since you guys should be relying on PROPATH instead of hardcoding absolute paths anyway.
So in short, here's what I'd like to hear back from you guys:
a. Which syntax would you prefer most: //, //<whitespace>, or some other syntax?
b. How many of you have code that would be broken if we implemented // as single line comments? If you do, would the benefit of having single line comments outweigh the detriment of potential code failure?
c. If you prefer alternative syntax, do you have any other character combinations in mind?
Thanks!
Hello, I'm one of the devs working on ABL. Nothing is set in stone yet but we're looking into implementing single line comments. Anyway, here are some issues we'd like your feedback on.
In an ideal world, we would use // as the starting delimiter for line comments. However, this clashes with statements like:
OS-DELETE C://tmp/tmp.txt.
A few other statements that possibly use // as valid syntax are most of the OS-* statements, INPUT, OUTPUT, RUN, SYSTEM-DIALOG GET-DIR/FILE, and COMPILE.
How would you guys feel if single line syntax was //<whitespace>? This would allow it to be differentiated from paths and wouldn't be too different from industry standard. On the other hand, it's a bit more tedious and it's pretty easy to forget that a space is required, especially if you have a background in languages like Java, PHP, or C++.
Another solution is to use different characters for single line comments. One of our most favorable alternative syntax is two semi-colons (;;). # is unfortunately out of the question since we allow that character in variable names. Using different characters removes the whitespace requirement but will vary differently from what's typical in other languages.
The last solution is to implement // without whitespace. This will cause behaviour changes that might break statements where a path is hardcoded with double slashes and without quoting the path. However, it'll be the simplest and most expected form of single line comments. Discussion here in HQ asserts that the number of people whose code will be broken with this change is very, very small since you guys should be relying on PROPATH instead of hardcoding absolute paths anyway.
So in short, here's what I'd like to hear back from you guys:
a. Which syntax would you prefer most: //, //<whitespace>, or some other syntax?
b. How many of you have code that would be broken if we implemented // as single line comments? If you do, would the benefit of having single line comments outweigh the detriment of potential code failure?
c. If you prefer alternative syntax, do you have any other character combinations in mind?
Thanks!
Flag this post as spam/abuse.
Shelley will be happy!
I wonder how common // is in path names. I think I would be inclined to include whitespace anyway, just for readability, but I would also think most path names were single slash and in quotes.
that will be cool, for me '//' should work just fine if you think that can be an issue with it appearing in valid statement enforce it so it's only considered if first (not empty) sequence on the line... I know Java lets you do it later on the same line where there is code already but I don't like it much so would vote for '//' at start of the line :)
that will be cool, for me '//' should work just fine if you think that can be an issue with it appearing in valid statement enforce it so it's only considered if first (not empty) sequence on the line... I know Java lets you do it later on the same line where there is code already but I don't like it much so would vote for '//' at start of the line :)
Flag this post as spam/abuse.
Unfortunately, since ABL is whitespace agnostic, there isn't really a way to implement // at the start of a line.
OS-DELETE
//dir/file.txt.
will be treated as:
OS-DELETE //dir/file.txt.
Besides, I would think one of the prime uses would be adding a short comment on the end of a line.
If // is problematic, would /// be any better? Like XML comments?
It definitely will be rarer but /// is still valid syntax in some statements. For example:
OS-DELETE ////path///to///file. /* this works because Unix eats up slashes */My question is, are there actually people who want to use this who would not put a space in anyway, just for readability?
It certainly wouldn't take long to reinforce!
I agree that //<whitespace> is the best. And it would make adding a quick comment much easier.
"'// " is a non-starter for me as any syntax token that requires
whitespace as part of the token a no-go.
I'd prefer
//*
This makes it similar to the current /* */, and enables constructs like:
//*
FOR EACH customer NO-LOCK:
/* stuff */
END.
//* */
Get rid of the leading "/" on the first in-line comment, and the
entire section's commented out.
Tim
On Thu, May 21, 2015 at 12:17 PM, aestrada
wrote:
> Single Line Comments
> Thread created by aestrada
>
> Hello, I'm one of the devs working on ABL. Nothing is set in stone yet but
> we're looking into implementing single line comments. Anyway, here are some
> issues we'd like your feedback on.
>
> In an ideal world, we would use // as the starting delimiter for line
> comments. However, this clashes with statements like:
>
> OS-DELETE C://tmp/tmp.txt.
>
> A few other statements that possibly use // as valid syntax are most of the
> OS-* statements, INPUT, OUTPUT, RUN, SYSTEM-DIALOG GET-DIR/FILE, and
> COMPILE.
>
> How would you guys feel if single line syntax was //? This would
> allow it to be differentiated from paths and wouldn't be too different from
> industry standard. On the other hand, it's a bit more tedious and it's
> pretty easy to forget that a space is required, especially if you have a
> background in languages like Java, PHP, or C++.
>
> Another solution is to use different characters for single line comments.
> One of our most favorable alternative syntax is two semi-colons (;;). # is
> unfortunately out of the question since we allow that character in variable
> names. Using different characters removes the whitespace requirement but
> will vary differently from what's typical in other languages.
>
> The last solution is to implement // without whitespace. This will cause
> behaviour changes that might break statements where a path is hardcoded with
> double slashes and without quoting the path. However, it'll be the simplest
> and most expected form of single line comments. Discussion here in HQ
> asserts that the number of people whose code will be broken with this change
> is very, very small since you guys should be relying on PROPATH instead of
> hardcoding absolute paths anyway.
>
> So in short, here's what I'd like to hear back from you guys:
>
> a. Which syntax would you prefer most: //, //, or some other
> syntax?
>
> b. How many of you have code that would be broken if we implemented // as
> single line comments? If you do, would the benefit of having single line
> comments outweigh the detriment of potential code failure?
>
> c. If you prefer alternative syntax, do you have any other character
> combinations in mind?
>
> Thanks!
>
> Stop receiving emails on this subject.
>
> Flag this post as spam/abuse.
--
Tim Kuehn: Senior Consultant - TDK Consulting Services
President - Ontario PUG
Program Committee Chair - PUG Challenge Americas,
Course Instructor: Intro to OO Concepts for Procedural Programmers
Skype: timothy.kuehn
Ph: 519-576-8100
Cell: 519-781-0081
Flag this post as spam/abuse.
> I believe // followed by a white space would be acceptable.
> Assuming that the editors (32bit Procedure Editor and PDSOE) do display this properly as a green comment.
That's a good point. SlickEdit doesn't allow us to define a comment sequence that includes a whitespace token. It will color both "//comment" and "// comment" green. I don't know how PDSOE will handle it.
I'm in the "//" camp (no whitespace). I doubt that there are more than a few instances of "RUN //hard/coded/path.p" and the like out there.
> SlickEdit doesn't allow us to define a comment sequence that includes a whitespace token. It will color both "//comment" and "// comment" green.
Spoke too soon. We can support // followed by whitespace in SlickEdit.
1) I gave a reason why I didn't care for "// " - what's your's for not
liking //* ?
If what I wrote wasn't enough - here's more:
2) Existing /* */ ABL comments and the single-line comment constructs
in other languages do not require a whitespace,
3) This means that going with "// " would result in an inconsistent
syntax between a single-line comments, multi-line comments, and the
single-line commenting style accepted by other languages.
4) //* has more flexibility in that it can be easily adapted to be
used with multi-line comment by deleting the leading "/". This means
more productivity, and more flexibility when testing / debugging as
opposed to "// " which can only be applied to one line (although one
could change "// " to "/* " pretty easily...)
On Thu, May 21, 2015 at 1:20 PM, Mike Fechner
wrote:
> AW: Single Line Comments
> Reply by Mike Fechner
> Don't really like //*
>
> And I don't get your argument about the white space. Many ABL tokens must be
> followed by a white space.
>
> Part of this enhancement is to make the ABL easier for non ABL developers.
> And // is the norm. And an additional white space will make it easier to
> read anyway
>
> Von meinem Windows Phone gesendet
> ________________________________
> Von: Tim Kuehn
> Gesendet: 21.05.2015 19:15
> An: TU.OE.Development@community.progress.com
> Betreff: Re: [Technical Users - OE Development] Single Line Comments
>
> Re: Single Line Comments
> Reply by Tim Kuehn
> "'// " is a non-starter for me as any syntax token that requires
> whitespace as part of the token a no-go.
>
> I'd prefer
>
> //*
>
> This makes it similar to the current /* */, and enables constructs like:
>
> //*
>
> FOR EACH customer NO-LOCK:
> /* stuff */
> END.
>
> //* */
>
> Get rid of the leading "/" on the first in-line comment, and the
> entire section's commented out.
>
> Tim
>
> On Thu, May 21, 2015 at 12:17 PM, aestrada
> wrote:
>> Single Line Comments
>> Thread created by aestrada
>>
>> Hello, I'm one of the devs working on ABL. Nothing is set in stone yet but
>> we're looking into implementing single line comments. Anyway, here are
>> some
>> issues we'd like your feedback on.
>>
>> In an ideal world, we would use // as the starting delimiter for line
>> comments. However, this clashes with statements like:
>>
>> OS-DELETE C://tmp/tmp.txt.
>>
>> A few other statements that possibly use // as valid syntax are most of
>> the
>> OS-* statements, INPUT, OUTPUT, RUN, SYSTEM-DIALOG GET-DIR/FILE, and
>> COMPILE.
>>
>> How would you guys feel if single line syntax was //? This would
>> allow it to be differentiated from paths and wouldn't be too different
>> from
>> industry standard. On the other hand, it's a bit more tedious and it's
>> pretty easy to forget that a space is required, especially if you have a
>> background in languages like Java, PHP, or C++.
>>
>> Another solution is to use different characters for single line comments.
>> One of our most favorable alternative syntax is two semi-colons (;;). # is
>> unfortunately out of the question since we allow that character in
>> variable
>> names. Using different characters removes the whitespace requirement but
>> will vary differently from what's typical in other languages.
>>
>> The last solution is to implement // without whitespace. This will cause
>> behaviour changes that might break statements where a path is hardcoded
>> with
>> double slashes and without quoting the path. However, it'll be the
>> simplest
>> and most expected form of single line comments. Discussion here in HQ
>> asserts that the number of people whose code will be broken with this
>> change
>> is very, very small since you guys should be relying on PROPATH instead of
>> hardcoding absolute paths anyway.
>>
>> So in short, here's what I'd like to hear back from you guys:
>>
>> a. Which syntax would you prefer most: //, //, or some other
>> syntax?
>>
>> b. How many of you have code that would be broken if we implemented // as
>> single line comments? If you do, would the benefit of having single line
>> comments outweigh the detriment of potential code failure?
>>
>> c. If you prefer alternative syntax, do you have any other character
>> combinations in mind?
>>
>> Thanks!
>>
>> Stop receiving emails on this subject.
>>
>> Flag this post as spam/abuse.
>
>
>
> --
> Tim Kuehn: Senior Consultant - TDK Consulting Services
> President - Ontario PUG
> Program Committee Chair - PUG Challenge Americas,
> Course Instructor: Intro to OO Concepts for Procedural Programmers
>
> Skype: timothy.kuehn
> Ph: 519-576-8100
> Cell: 519-781-0081
> Stop receiving emails on this subject.
>
> Flag this post as spam/abuse.
>
> Stop receiving emails on this subject.
>
> Flag this post as spam/abuse.
--
Tim Kuehn: Senior Consultant - TDK Consulting Services
President - Ontario PUG
Program Committee Chair - PUG Challenge Americas,
Course Instructor: Intro to OO Concepts for Procedural Programmers
Skype: timothy.kuehn
Ph: 519-576-8100
Cell: 519-781-0081
Flag this post as spam/abuse.
Get rid of the leading "/" on the first in-line comment, and the entire section's commented out.
I don't think that is correct. The trailing */ would be part of the last single line comment and therefore would not be seen.
It also isn't a use case I find very compelling.
While requiring a whitespace seems unaesthetic, the whitespace *is* going to improve readability and so I would think most people would use it anyway. While the number of unquoted // in people's applications may be small, I have come to believe that almost everything is out there somewhere and those people could be quite negatively impacted.
How would you guys feel if single line syntax was //<whitespace>?
-- Tom Bascom 603 396 4886 tom@greenfieldtech.com[/collapse]
Reply by Mike FechnerThe one and only reason for me is (given in my earlier reply already) is that // is the norm is most modern control languages.
Von meinem Windows Phone gesendet
Von: Tim Kuehn
Gesendet: 21.05.2015 19:37
An: TU.OE.Development@community.progress.com
Betreff: Re: [Technical Users - OE Development] AW: Single Line Comments
Reply by Tim Kuehn1) I gave a reason why I didn't care for "// " - what's your's for not
liking //* ?
If what I wrote wasn't enough - here's more:
2) Existing /* */ ABL comments and the single-line comment constructs
in other languages do not require a whitespace,
3) This means that going with "// " would result in an inconsistent
syntax between a single-line comments, multi-line comments, and the
single-line commenting style accepted by other languages.
4) //* has more flexibility in that it can be easily adapted to be
used with multi-line comment by deleting the leading "/". This means
more productivity, and more flexibility when testing / debugging as
opposed to "// " which can only be applied to one line (although one
could change "// " to "/* " pretty easily...)
On Thu, May 21, 2015 at 1:20 PM, Mike Fechnerwrote:
> AW: Single Line Comments
> Reply by Mike Fechner
> Don't really like //*
>
> And I don't get your argument about the white space. Many ABL tokens must be
> followed by a white space.
>
> Part of this enhancement is to make the ABL easier for non ABL developers.
> And // is the norm. And an additional white space will make it easier to
> read anyway
>
> Von meinem Windows Phone gesendet
> ________________________________
> Von: Tim Kuehn
> Gesendet: 21.05.2015 19:15
> An: TU.OE.Development@community.progress.com
> Betreff: Re: [Technical Users - OE Development] Single Line Comments
>
> Re: Single Line Comments
> Reply by Tim Kuehn
> "'// " is a non-starter for me as any syntax token that requires
> whitespace as part of the token a no-go.
>
> I'd prefer
>
> //*
>
> This makes it similar to the current /* */, and enables constructs like:
>
> //*
>
> FOR EACH customer NO-LOCK:
> /* stuff */
> END.
>
> //* */
>
> Get rid of the leading "/" on the first in-line comment, and the
> entire section's commented out.
>
> Tim
>
> On Thu, May 21, 2015 at 12:17 PM, aestrada
> wrote:
>> Single Line Comments
>> Thread created by aestrada
>>
>> Hello, I'm one of the devs working on ABL. Nothing is set in stone yet but
>> we're looking into implementing single line comments. Anyway, here are
>> some
>> issues we'd like your feedback on.
>>
>> In an ideal world, we would use // as the starting delimiter for line
>> comments. However, this clashes with statements like:
>>
>> OS-DELETE C://tmp/tmp.txt.
>>
>> A few other statements that possibly use // as valid syntax are most of
>> the
>> OS-* statements, INPUT, OUTPUT, RUN, SYSTEM-DIALOG GET-DIR/FILE, and
>> COMPILE.
>>
>> How would you guys feel if single line syntax was //? This would
>> allow it to be differentiated from paths and wouldn't be too different
>> from
>> industry standard. On the other hand, it's a bit more tedious and it's
>> pretty easy to forget that a space is required, especially if you have a
>> background in languages like Java, PHP, or C++.
>>
>> Another solution is to use different characters for single line comments.
>> One of our most favorable alternative syntax is two semi-colons (;;). # is
>> unfortunately out of the question since we allow that character in
>> variable
>> names. Using different characters removes the whitespace requirement but
>> will vary differently from what's typical in other languages.
>>
>> The last solution is to implement // without whitespace. This will cause
>> behaviour changes that might break statements where a path is hardcoded
>> with
>> double slashes and without quoting the path. However, it'll be the
>> simplest
>> and most expected form of single line comments. Discussion here in HQ
>> asserts that the number of people whose code will be broken with this
>> change
>> is very, very small since you guys should be relying on PROPATH instead of
>> hardcoding absolute paths anyway.
>>
>> So in short, here's what I'd like to hear back from you guys:
>>
>> a. Which syntax would you prefer most: //, //, or some other
>> syntax?
>>
>> b. How many of you have code that would be broken if we implemented // as
>> single line comments? If you do, would the benefit of having single line
>> comments outweigh the detriment of potential code failure?
>>
>> c. If you prefer alternative syntax, do you have any other character
>> combinations in mind?
>>
>> Thanks!
>>
>> Stop receiving emails on this subject.
>>
>> Flag this post as spam/abuse.
>
>
>
> --
> Tim Kuehn: Senior Consultant - TDK Consulting Services
> President - Ontario PUG
> Program Committee Chair - PUG Challenge Americas,
> Course Instructor: Intro to OO Concepts for Procedural Programmers
>
> Skype: timothy.kuehn
> Ph: 519-576-8100
> Cell: 519-781-0081
> Stop receiving emails on this subject.
>
> Flag this post as spam/abuse.
>
> Stop receiving emails on this subject.
>
> Flag this post as spam/abuse.
--
Tim Kuehn: Senior Consultant - TDK Consulting Services
President - Ontario PUG
Program Committee Chair - PUG Challenge Americas,
Course Instructor: Intro to OO Concepts for Procedural Programmers
Skype: timothy.kuehn
Ph: 519-576-8100
Cell: 519-781-0081Stop receiving emails on this subject.Flag this post as spam/abuse.
Stop receiving emails on this subject.Flag this post as spam/abuse.
4) //* has more flexibility in that it can be easily adapted to be used with multi-line comment by deleting the leading "/". -
By the same token, changing // to /* is a single character change which accomplishes the same purpose.
Reply by Thomas Mercer-HurshGet rid of the leading "/" on the first in-line comment, and the entire section's commented out.
I don't think that is correct. The trailing */ would be part of the last single line comment and therefore would not be seen.It also isn't a use case I find very compelling.
While requiring a whitespace seems unaesthetic, the whitespace *is* going to improve readability and so I would think most people would use it anyway. While the number of unquoted // in people's applications may be small, I have come to believe that almost everything is out there somewhere and those people could be quite negatively impacted.
Stop receiving emails on this subject.Flag this post as spam/abuse.
Reply by Thomas Mercer-Hursh4) //* has more flexibility in that it can be easily adapted to be used with multi-line comment by deleting the leading "/". -
By the same token, changing // to /* is a single character change which accomplishes the same purpose.
Stop receiving emails on this subject.Flag this post as spam/abuse.
How would you guys feel if single line syntax was //<whitespace>?
--
Tom Bascom
603 396 4886
tom@greenfieldtech.com
Flag this post as spam/abuse.
Reply by Tim Kuehn"'// " is a non-starter for me as any syntax token that requires
whitespace as part of the token a no-go.
I'd prefer
//*
This makes it similar to the current /* */, and enables constructs like:
//*
FOR EACH customer NO-LOCK:
/* stuff */
END.
//* */
Get rid of the leading "/" on the first in-line comment, and the
entire section's commented out.
-- Tom Bascom 603 396 4886 tom@greenfieldtech.com[/collapse]
Reply by Tim Kuehn"'// " is a non-starter for me as any syntax token that requires
whitespace as part of the token a no-go.
--
Tom Bascom
603 396 4886
tom@greenfieldtech.com
Flag this post as spam/abuse.
Peter, want to bet that somewhere out there someone has // not in quotes and a path name with a leading space?
I wouldn't be surprised, given what I have seen.
Reply by ChUIMonster[collapse]On 5/21/15 1:15 PM, Tim Kuehn wrote:
Reply by Tim Kuehn"'// " is a non-starter for me as any syntax token that requires
whitespace as part of the token a no-go.
Why? In what way is requiring white space a "no-go"?
I do not understand the objection.
I'd prefer
//*
This makes it similar to the current /* */, and enables constructs like:
//*
FOR EACH customer NO-LOCK:
/* stuff */
END.
//* */
Get rid of the leading "/" on the first in-line comment, and the
entire section's commented out.
That would be a readability nightmare. Nobody would ever be able to make sense out of code that does stuff like that. I can just see the "programmer interview" trick questions now.
No way. This kind of arcane trickery makes Hungarian Notation look like a good idea. You might as well define pre-processor directives to create comments.
I find myself in agreement with Dr. Tom. I need a drink.
-- Tom Bascom 603 396 4886 tom@greenfieldtech.comStop receiving emails on this subject.Flag this post as spam/abuse.
Why not just formally document and support the already existing single line comment features?
define variable cMsg as character no-undo.
assign cMsg = "Test". .This is my end of line comment.
.This is a single line comment.
message cMsg view-as alert-box.
Tim, while it is true that whitespace is not part of other tokens, it is also true that other tokens depend on whitespace.
definevariablexascharacter.
is not a valid ABL construct. In fact, I would guess that the existing comment token is one of the rare cases when whitespace or some other delimiter is not required.
I would say that // was better than //* for two reasons. Only one key and more easily differentiated from /*.
@wrpkm2
The . single line comment is really a bug and also not reliable.
The other obvious question to ask is: Do we care about single line comments at all?
It seems like // followed by whitespace is getting the most votes, but that's only 1 char less than /* and */
Should the bug either be fixed, since most people don't even know they may have commented out some of their logic, or make it an official feature and made reliable for those who may already be using it?
Bill.
Reply by Thomas Mercer-HurshTim, while it is true that whitespace is not part of other tokens, it is also true that other tokens depend on whitespace.
definevariablexascharacter.
is not a valid ABL construct. In fact, I would guess that the existing comment token is one of the rare cases when whitespace or some other delimiter is not required.
I would say that // was better than //* for two reasons. Only one key and more easily differentiated from /*.
Stop receiving emails on this subject.Flag this post as spam/abuse.
Correct, Alex. I guess that recent experiences have led me to be cynical about what one can find in people's code bases.
Tim, the point is that whether you consider the whitespace as part of the token or a necessary separator is really academic. Pretty much every other token *except* /* requires a separator and even for it readability is improved with a separator.
I don't like very much using a trailing white space as part of a token, find it confusing and kind of turns down main goal of using //, in most other languages that trailing space would be not required.
Just as a personal preference I found /= or /- quite consistent with current comments and also appropriate for single line comments.
Production code should not contain paths pointing to specific servers or IP addresses, not even quoted.
If it does, it will bite you at some stage. Chances are that such hard coding is already placing constraints on the network layout and architecture, most likely preventing something that is actually needed to be done. If we add "... and now because of the same reason we cannot upgrade to the next version of OpenEdge... " that Progress is just doing the customer a favour by increasing the number of arguments to fund a project to fix the mess and teaching them about good coding.
So I would go for the plain and simple and common "//", with no white space required.
But just to be fair about the argument that "// " will be unnatural due to the fact that the white space should not be part of a token: The fact is that a line comment is in essence a "weird" construct. It a) starts with a specific sequence, b) contains "garbage" that must be ignored, until c) the terminating character (line end) is found.
The point of a single line comment is that it must be easy and fast to type. The mere tediousness of the block comment normally cause me to omit a quick note which would have been kind to the next guy reading the code (often me).
Some alternatives I can think of, although they do not match any other language I know, are simple enough to achieve the objective:
**
/?
But non-American keyboard layouts would most likely make /? less practical.
I cannot imagine any other use case for that, unless, of course, somebody used that in a weird file name, which is unlikely given that ? and * are wildcards in both Unix and Windows. But then again, back in my v.7 days I had a colleague who managed to create a file named "LPT1:" from within Progress on a DOS machine. Now try to get rid of that file....
So just want to clarify, no one here so far has seen or used code in production that has two slashes hardcoded into a path?
I haven't seen it ... I can't imagine why it would be there (more likely as a part of a URL ... in particular I can't imagine why it would not be quoted ... but, at the same time, I have come to believe that everything is out there somewhere, no matter how bizarre and seemingly against all rules of best practice.
what about [] and () and {}
[0] no spaces between tokens
{foo.i}
do:
. can end a statement wihout a space
if true then.
plenty more ;)
no sentence in the english language can end with the word "the".
except that one ;)
On 21 May 2015 at 19:35, Thomas Mercer-Hursh
wrote:
> RE: Single Line Comments
> Reply by Thomas Mercer-Hursh
>
> Correct, Alex. I guess that recent experiences have led me to be cynical
> about what one can find in people's code bases.
>
> Tim, the point is that whether you consider the whitespace as part of the
> token or a necessary separator is really academic. Pretty much every other
> token *except* /* requires a separator and even for it readability is
> improved with a separator.
>
> Stop receiving emails on this subject.
>
> Flag this post as spam/abuse.
--
Julian Lyndon-Smith
IT Director,
dot.r
http://www.dotr.com
I grepped through some code for occurrences of "//". These are the main patterns I found:
Is it safe to assume that, if "//" became the SLC token, it would be ignored if it were within quotes or within a /* */ comment?
I grepped through some code for occurrences of "//". These are the main patterns I found:
Is it safe to assume that, if "//" became the SLC token, it would be ignored if it were within quotes or within a /* */ comment?
Flag this post as spam/abuse.
guess I'm missing the point here... just because the language allows one to use an unquoted path in some statements - which not only should be corrected in the language to make it less ambiguous but inside application as well because it's a clear indication of hard-coded values that should be part of some configuration - you guys look now for some 'proprietary' combination for single line comment?
it's bad enough ctrl-shift-c doesn't toggle slc in pdsoe as per default mapping in eclipse, if we can't use what was becoming more or less the default (//) then I will cast my vote for perl's one '#' or we can start a debate on what currency sign we should use: dolar, euro or pound :)
REM... Was good enough for VB and Batch files! nuff said.
Or, go the way of the linux conf files with a semi-colon, eg:
; this is my comment, yup!
I have not and if my code base has that anywhere I would be willing to fix it, rather than to accept some awkward alternative.
I have not and if my code base has that anywhere I would be willing to fix it, rather than to accept some awkward alternative.
Flag this post as spam/abuse.
Mike has a valid point - adding another excuse to prevent upgrading is a much bigger risk than the benefit of an added incentive to fix bad code.
> we're looking into implementing single line comments
Why bother?
Just look at all this discussion, just to introduce a feature we can easily live without, in order to save very few characters when typing...
[quote user="ske"]
> we're looking into implementing single line comments
Why bother?
Just look at all this discussion, just to introduce a feature we can easily live without, in order to save very few characters when typing...
[/quote]
Valid point, if PSC is looking into making the language more consistent with the likes of JS, C# and Java I think that == and != would be far more valuable. Not to mention +=, -=, *= etc
> we're looking into implementing single line comments
Why bother?
Just look at all this discussion, just to introduce a feature we can easily live without, in order to save very few characters when typing...
Re an excuse to not upgrade, would it help to have a startup parameter that reverts back to the old behavior, I.e., disallows // comments? People could upgrade and use it to give them time to fix there naked, absolute paths (or of course just carry on as usual). Or do we already have too many startup parameters?
I think making it //{space|tab} is a simpler solution than having another startup parameter. Besides, as others noted, it makes things more readable.
To be honest, I will be happy with any symbol as long as it is easy to type.
Why bother?
Because Shelley has been asking for it for years ... :)
I am all in favor of making Shelley happy!
I would much rather have ++ and quite a few other things added to the ABL/4GL way before we worry about potentially making people change code to accommodate comments without a terminating "*/ " tag.
I just don't see the huge improvement to be honest.
Product Management has asked the Language team to investigate several additions / modifications to the language. This thread deals with adding a single line comments to the ABL, another thread dealt with the addition of a STRICT mode to the ABL compiler and the third change is the addition of ++, -- syntax. We have not yet begun the conversation concerning ++ / -- and we will pick that up in the future. It is clear from this Community thread that the addition of ++, -- would be beneficial to our Community.
@Mike Fechner
A side note is //<whitespace> doesn't just include spaces and tabs but also newlines and carriage returns. This allows empty comments for whatever reason.
Heartily agreed. We rolled our own += -= ++ stuff years ago, but i think the demand for single line comments is minimal.
JS, C#, and Java should be looking to us for ways to improve! (And maybe SQL could learn a thing or 3).
Laura,
If you introduce new language behaviour that potentially breaks existing code (even though it may be rare), and you plan on adding a new client param to help ease the migration, please make the param default to the existing behaviour and take a non-default value to permit the new behaviour. Otherwise I don't see the point.
Reply by Rob FitzpatrickLaura,
If you introduce new language behaviour that potentially breaks existing code (even though it may be rare), and you plan on adding a new client param to help ease the migration, please make the param default to the existing behaviour and take a non-default value to permit the new behaviour. Otherwise I don't see the point.
Stop receiving emails on this subject.Flag this post as spam/abuse.
Laura,
If you introduce new language behaviour that potentially breaks existing code (even though it may be rare), and you plan on adding a new client param to help ease the migration, please make the param default to the existing behaviour and take a non-default value to permit the new behaviour. Otherwise I don't see the point.
Flag this post as spam/abuse.
Just to be clear, my previous post was a response to Rob's post. I'm in full agreement with Tim.
I don't have a huge issue with this being implemented as the default going forward. As long as we get a parameter to turn it off.
I think the real danger is having people recompile their code and get different results when they compile. Things that don't result in compile errors.
It would be nice to have some kind of compiler option/warning to let people know that their code is being compiled differently than with a previous version. Some other products let you set a compatibility mode for either the actual compile or just a strict check of your code. This would also be nice if you are a vendor supporting multiple versions of OE with one code base.
Another vote for "//" (no whitespace) from me
No need to repeat the arguments already mentioned before...
I vote for "//" (no whitespace).
(if this is breaking exising code it can be fixed easily; adding a startup/compiler parameter to not use single line comments would be beneficial for those who cannot fix the code - should be only a few occasions anyway)
Another vote for "//" with no whitespace
I don't know what to think of myself...
1,700 .w
2,650 .p
23 cls (just adopting)
An not even one \\ nor // on code
(I vote for i++, //, and strict mode)