|
Yes, which is what I do... as far as you know  . (I actually wrote my own simple IDE.)
I don't like that notepad can't be flexible on TABs. I do use it for XML though.
|
|
|
|
|
In my opinion... .net should never have been released to the public with such inconsistencies as these. 
System.DateTime.UtcNow .ToString ( "hh:mm:ss" ) ;
System.DateTime.UtcNow.TimeOfDay.ToString ( "hh\\:mm\\:ss" ) ;
new System.ArgumentException ( message , paramName ) ;
new System.ArgumentNullException ( paramName , message ) ;
|
|
|
|
|
Them's a beatin'.
I’ve given up trying to be calm. However, I am open to feeling slightly less agitated.
|
|
|
|
|
I'm guessing it has to do with people's obsessions about breaking changes.
|
|
|
|
|
That's why they can't fix it now, but it doesn't explain how things got that way to begin with, from v1 and earlier.
|
|
|
|
|
From v1? Gee. Maybe there were bun fights over the interface. 
|
|
|
|
|
They probably copied it from Java and had to swap the order to avoid copyright infringement.
Before the judge:
See Java has its parameters in the same order for both. DotNet 1.0 is different.
|
|
|
|
|
The DateTime vs TimeSpan is more insidious than you think. DateTime.UtcNow.TimeOfDay.ToString("hh\\:mm\\:ss") will always use ":" as the separator, whereas DateTime.UtcNow.ToString("hh:mm:ss") will use the current culture's time separator. Whilst the default seems to use ":" consistently, I believe the user can override this in the OS settings.
var format = new DateTimeFormatInfo { TimeSeparator = "#" };
DateTime.UtcNow.ToString("hh:mm:ss", format);
DateTime.UtcNow.TimeOfDay.ToString("hh\\:mm\\:ss", format);
The argument exception one is annoying, but I can sort-of understand how it came to be. With an ArgumentNullException, there's an obvious default error message, and the main thing you care about is the name of the argument which was null. But with an ArgumentException, there's no obvious default error message, and the error could be caused by a combination of parameters, so the message is the main thing, and the parameter name is optional.
Since C# 4 introduced named parameters, you can use them to make the invocations consistent:
new ArgumentException(paramName: nameof(foo), message: "Bar");
new ArgumentNullException(paramName: nameof(foo), message: "Bar");
NB: Starting with .NET 6, the recommendation is to use ArgumentNullException.ThrowIfNull(parameter); instead of if (parameter is null) throw new ArgumentNullException(nameof(parameter));:
ArgumentNullException.ThrowIfNull Method (System) | Microsoft Docs[^]
Introduce static methods to allocate and throw key exception types. · Issue #48573 · dotnet/runtime · GitHub[^]
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
I don't use .net 6 .
How would I specify the message though?
Edit: In fact I don't use any features of C# 4 either. And it may be that the only features I use of C# 3 are Extension Method, Collection Initializer, and Object Initializer.
I just ran through some of my libraries, seeing which require C# 3. Most do, but one will actually compile with C# 2.
And I had actually forgotten about Collection Initializer until this week -- I used it in two places in a piece of code I wrote in 2014, to initialize a Dictionary.
Last week I wrote some code which used a Dictionary Initializer, not realizing it is a C# 6 feature, and then rewrote it as a Collection Initializer when I found out.
In the code I am working on, the Dictionary Initializer provides no benefit over the Collection Initializer.
modified 27-Aug-22 13:26pm.
|
|
|
|
|
You wouldn't; the ThrowIfNull method always uses the default error message, which leads to more consistent errors.
You could override the parameter name, but it's best to let the compiler fill it in using the [CallerArgumentExpression] attribute.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Seems pointless anyway. Why would I want a "default error message"? Or, if I do, I'd make that an inner exception and provide a meaningful message in the main exception.
So far I have found no useful features of C# 6... except...
I just found that "dictionary initializer" is a C# 6 feature and I have been toying with that for a week or so now. Why didn't this exist since the advent of initializers?
I also just dabbled with string interpolation -- which I heard about, but hadn't bothered with -- and, as expected, it provides no benefit to me. It works only with string literals, and most format strings I use are not literals. It looks like it would lead to bad practices. In particular, how do you use string interpolation with globalization?
Anyway, now that I know that I am using a v6 compiler, I can see if that's why my recent builds refuse to execute on the servers. I'll specify v4 and see if they succeed then.
Edit: In case anyone is curious. Yes, once I rebuilt with an earlier compiler (v5), I was able to run the utility on the server. I am not in control of what versions of things (e.g. .net) are installed on my laptop and the servers, but it's never the latest version.
modified 27-Aug-22 13:27pm.
|
|
|
|
|
Aren't there similar quirks with the DateFormat?
And what about NumberFormat (like decimal separator etc.)?
Oh sanctissimi Wilhelmus, Theodorus, et Fredericus!
|
|
|
|
|
I think so. Plus in the past I've run into issues with other limitations on what can be specified in format strings.
Which led to this : ApplyFormat[^]
And this week I've been working on another formatter, kinda sorta similar to string interpolation, but not really.
|
|
|
|
|
How much money should they spend, in your opinion, to have parameters in the same order, even if it doesn't make sense? 
Bastard Programmer from Hell 
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
My programming career has been blessed by an affair or two with TECO the text editor.
Browsing around I can find very few examples of TECO code. So I decided to provide some for you.
Wait, if you dig hard enough you can always find TECO code by
guys like Stanley Rabinowtiz but what about every day, run of the mill
TECO macros?
For starters see DATE. Enjoy!
If you spot a bug then please submit a PR.
Dang! My '58 Renault Dauphine has another flat tire.
|
|
|
|
|
Unsure what you're talking about. I used TECO a bit on the high school PDP-11 in 1983/4. It was just an editor.
Most of the time when I was using OpenVMS (1986 - 2002) I used EDT and I defined a few macros for myself, but nothing special and I wouldn't call them "code".
|
|
|
|
|
You stuck with EDT and did not switch to EVE/TPU?
Calling CodeProject:: PIEBALDconsult…
Calling CodeProject:: PIEBALDconsult…
|
|
|
|
|
Correct. Though EDT became an option of TPU eventually -- EDIT/EDT .
I never got the hang of EVE and I could never figure out how to exit it whenever I started it accidently.
I still have a file of EDT macros I use when I use my OpenVMS systems (which is rare).
I also knew developers who used VI rather than TPU-based editors. An amber-screen dumb terminus doesn't know the difference.
Again, I don't adopt new things without some good reason to do so. I certainly prefer a screen editor to a line editor.
Always consider what happens if you have to work with an older system without the new tool(s). Such as, does the version of OpenVMS/VAX I have on my MicroVAX even support TPU? (I think it does.) One reason I bought the MicroVAX is because VAX BASIC has Immediate Mode  .
About twenty years ago I was asked to write a program with only the tools installed on a fresh install of Windows XP (?) -- e.g. notepad and CSC.
Developers who have no clue how to write code without an IDE may find themselves unable to make any progress.
Edit: When I first learned BASIC on the PDP-11 (in 1983), the teacher taught us to use EDT in line mode (was there no screen mode yet?), but the cool kids used TECO.
modified 1-Sep-22 13:59pm.
|
|
|
|
|
Do you see what is wrong with the Base64 encoded data (below)?*
*Find answer at bottom of this entry.
Also, don't try decoding the data because it is non-sense because it is base64 of encrypted data.
Had a problem where my Base64 data (all of a sudden) was being corrupted.
However, it is very subtle (see ANSWER at bottom). HINT: Just one char was being corrupted.
Data Only Corrupted After Posting
I couldn't understand this. The data (before I posted it was completely fine).
Only after posting data did it get corrupted (and it's not a URL-encoding thing).
Actually, that is incorrect. The data is posted to the web site & saved in DB with no corruption.
Only after the data is returned as a part of a JSON object is the base64 data corrupted. CRazy!! 
I Finally Found This Argument At Github - Spoiler ALERT!!
+ sign is changing into \u002B using JsonSerializer.Serialize · Issue #35281 · dotnet/runtime · GitHub[^]
This is a very WEIRD (and obscure) thing. I can't believe I finally figured this out. Now, I will have to implement a fix. Discovering the problem was extremely difficult because the base64 data is upwards of 40K.
Have any of you seen this?
jHx4uha8sCRyiqv8nRVJpRoQPx45ghciXg6PJb8qrxORwmMTN6cLlDIh4PVZenZvh3saEtlGAxZlI2Wm\u002BumDIiIs/r9vU5XgnMMF\u002Bk5TnvzNSLvYaTY41mS4FNZ8yshdVFn\u002Bq2UolJzz8ldlycDW1a7JfWKS88XNaBVgbZYjrSquDjCHOwIY8yGzxHnv70BDHEgHz6IUtZ7gEzKQ/dlVabYe7D2/QfU0Mtobx/LVkxa/oiujTaoiCLIQdkmALGbQqj/rtdLlOzKWjqLMpa/EhwGTA5unrEJMR\u002BDgKIJ5kxwoffKwVeydXlz1GY9WcyJrFf1xJr2CmKhUsbbXQQ0Qcgi80FJcupEQr\u002Bd4jclGeVbyFla40Ncm7ZjDeRVQ5coP2n1VyHTosWpvk7WqDIv1URbD8Xx3qfrXr2LsbS\u002Bzhe67bXNv4wekJfkvfxY8dh4Qjz9ZW0PBwIgW6KdtmCEKsURRWl5m8OvLxkL8iWuXwG\u002BdQeTSJb0Ew/AohuSpuiSeV5REkEagMoGnHdV6sLGo8kselY4sh1SqtIdoRq5E6nO60V7kzcCfm4MgdmwWEuRRxtJeeEl59dDvvOOOefbYCHLWGONVQ4/hpLPxnU2beyPoz7j9oWz2hIMgjTlQgzupzIZzjdzu7O62PDRorm8rVnZAmLFnNbAmFCzpgLsB1HZrTL5/MXeEdUz2WuKjJPAi4q\u002BnPddo0xm6bkvKXoGWJbwFAoxaWD7hffcvuurAkIqPH2S8CgP3cmnLiM6Qg65k7Sy51T81ab92g92rBJ\u002B8BFVPCDVdGsy6BblFP2/KQ6\u002BoCllRD\u002BIqNqIfdfzmJUp2WEEpviwP\u002B9IhGuGC2flCrMclKaAmTuZLyijgQkC2\u002BEb7hU5GoA8h5ic3hOFSOhmUo20/LIiIIj3jUanfxJLLW6MTY3c5WNJlNUz0ucwGRUNqO2VMxsPnWp05M3aGU4kxYIracZwmvqeQKgGX59vhPo5GhmFxZroVkSO7\u002BEOWRG/J1et/5dFslN3dZDLFSIBvrA5pJF7BuEZPsbcWTOWxnrWZl\u002BeGouVoC8KfEfsCgZkbBKB1bR2ark7vZl6aEP1OrjuNonHGODutBaogq6V39T/4w86gz2Ow3qDfbGJh2nqJbE2JTNUbN/UbsEmKfdz7JC2jDjTZ7M3Cl0LXsLZM67\u002BFYZxvBzyKUsjXV3S1eHqLrk/i98yWs9YbSEHurIb7wggOac3MlzLz\u002BYCye2UAQxVE6vt66cv3wXBXLLlfwy3rBNVqSLv60
ANSWER
If you guessed that the \u002B should actually be a + character, you are amazing!!
|
|
|
|
|
Roger,
I'm sure that you've figured this out by now. That escaping behavior is actually in the JSON specification.
RFC 8259 - Section 7[^]
|
|
|
|
|
Yeah, it seems like it is a normal thing. It seems that it was just altering a test I had (that didn't parse it as json) that used the base64 encoded data and that is where I was seeing the issue.
It's part of a larger challenge so it looks like it was a false-positive for me.
Thanks
|
|
|
|
|
| Gads, I remember dealing with a similar issue. Turned out the issue was that the front-end wasn't using encodeURIComponent in the utility app for setting password.
|
|
|
|
|
Think that's because Json had a quarrel with the Argonauts some time ago
|
|
|
|
|
I can understand why - he got fleeced[^].
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Ah, learned something new, should have known that being Dutch:
Quote: In matters of commerce the fault of the Dutch Is offering too little and asking too much
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
