it's perfectly valid for a filename to start with two dashes.
It is also perfectly valid for a filename to start with a single dash. But that is irrelevant to the issue.
The issue is with the parameters / command line options / arguments. This is the part AFTER the program name. $args contains an array of everything after the filename, delimited by breaking space (and a few other scenarios). Single hyphen parameters within these arguments can be automatically parsed and set. Double hyphen parameters are not a documented feature, are unsupported, and may exhibit behaviour that the user does not expect.
The term 'Best Practice' exists for a reason.
That's even more stupid - any author of any system could at any time change the rules and break existing programs. In fact, Unix is more prone to this than Windows, going by your earlier statement.
My post is not about changing existing rules, but leaving room to add more features. A single hyphen is to be used for command line arguments. This leaves a double hyphen available for a future use; whether that be implementing GNU-like syntax, some new security paradigm, a switch to set a flag, or any number of uses.
There's no guarantee Microsoft won't decide to break programs using their established conventions too - except that it would be bloody stupid to do so. Not to mention that even their own "conventions" vary significantly from tool to tool.
Standards, conventions, guidelines, and rules are all there for a reason. It is one method of future proofing and is vital to follow for a program to exhibit expected behaviour. Why be a maverick and use double hyphen when there is no need whatsoever other than to be different. That is hipster-coding.
I don't think I'm going to worry about the possibility that Microsoft might stop passing command line options to programs. It's a ridiculous fear, and the fact that you got even one mod point for this shows how far Slashdot has fallen.
Microsoft won't stop passing command line options to programs - that would break every program. What Microsoft MIGHT do, and it would be both safe and fair for them to do so, is have the shell examine the parameter string, cut out double hyphen parameters, pass the remaining string to ARGV, then act on those cut parameters separately prior to or simultaneously with program execution. If developers have acted competently and followed the conventions, this will not cause any issues.
This is not a fear - it is just common sense. I got a single +1 Informative as someone has either learned something, has thought about something they haven't put their mind to before, or thinks that someone else may benefit from the information. I am not a developer. I am not a Windows user. But I read, and I absorb. It is called listening. That more people don't do it shows how far society has fallen.
Why do you claim --help is invalid on Windows?
It will work (at the moment) but goes against the conventions set by Microsoft.
Microsoft could, at any time, change the way it interprets a double hyphen, breaking your program.
It is safe at the moment because Windows passes the entire parameter string via ARGV
-h? Next time, use all three of these: -?, -help, --help. I'm probably not going to try throwing -h at a program without having a clue what it might do.
For non-Windows systems:
-h is Valid
-? is Invalid as '?' is a special parameter that may be expanded by the shell
-help is Invalid on GNU/Linux (though used often by ported applications)
--help is Invalid on older Unix systems.
For newer Windows systems:
-? is Valid (and mandatory)
-Help is Valid (and mandatory)
--help is Invalid
-help is Valid
-h is Valid
-h is the safest option
Thirded. No clue what this is actually about.
I think this is a story about a guy who logs into some banking/trading platform only to leave it idle and proceed to random web browsing in other tabs of the same browser instance.
I'm sure the story doesn't end well.
Work is the crab grass in the lawn of life. -- Schulz