|
I think it's similar to the old "bool-vs-enum" arguments that have been around for many years. An appropriately-named enum can certainly make the calling code easier to read than a bunch-o-bools, although it can lead to some interesting definitions[^]. 
Given how recent the book is, I'm surprised the author hasn't progressed to record structs[^]; perhaps that will come later?
public readonly record struct Speed(double Amount);
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
modified yesterday.
|
|
|
|
|
Richard Deeming wrote: An appropriately-named enum can certainly make the calling code easier to read than a bunch-o-bools, although it can lead to some interesting definitions[^].
In my student days, DEC had a discussion group system called COM, not unlike the far more well known NetNews, running on DEC-10 and DEC-20 mainframes. Whenever the software asked the user a yes/no question (such as "Delete entry?") there were in fact three options: Yes, No, Maybe. If the user chose Maybe, a random generator was used to choose between Yes and No.
This was a fully documented, well known feature.
I believe this feature existed in the old DEC-10/20 version. COM was completely rewritten as a platform independent system and renamed PortaCOM. I used the system in the transition from COM to PortaCOM; maybe the 'Maybe' option came with the PortaCOM rewrite. I didn't discover it until we had switched to PortaCOM.
|
|
|
|
|
I'm a total n00b here with record structs... but reference types that offer value-based equality checking? That's actually pretty cool.
Jeremy Falcon
|
|
|
|
|
He failed step 3. Angle is not very well implemented, as it does not specify what unit it uses. Either call it Radians, or specify the unit in the constructor and getter.
Ironically, this could possibly be implemented by inheritance. Angle being the base class and Degrees, Radians, Turns and Gons (optionally Longitude and Latitude) being the sub classes, although this would force it to be a class.
As implemented the client of this function could still create an angle of 90 (thinking degrees) and pass this in and get a point at 90 radians.
I agree that is is a good idea to make structs immutable. I have seen so many bugs caused by trying to alter a Point or Size but the code is altering a copy, not the original.
Is implementing structs for these a good idea? Possibly. I have implemented Angle as a class before - mainly for user display. I have also just used angleDegrees and angleRadians. Choose wisely.
The advantages are it forces the correct type to be passed in.
The disadvantages are a little bit of speed and extra code.
Would naming the angle as angleRadians be enough to eliminate most errors?
Do we need explicit casts on Radians so we can use (Radians)Math.PI?
Personally I prefer a plain double, named well, although an explicit type can be useful.
|
|
|
|
|
"I prefer a plain double, named well"
I agree. Working in embedded systems where units are very important, I try to always include units at the end of the variable name. It causes a mental check when you start misusing the variable. But I also like a little more rigidity to avoid really stupid errors. I'm thinking of the Mars Climate Orbiter that lawn darted due to a units conversion issue. Errors like this boggle my mind. Every engineering system should be in metric. Period. If you want to convert something to English - that's a presentation issue, but I digress.
This conversation is an excellent read.
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
charlieg wrote: I'm thinking of the Mars Climate Orbiter that lawn darted due to a units conversion issue.
A less known story of a similar kind: In its infancy in the late 1960s, the Norwegian computer manufacturer Norsk Data started buying standard 19" power supplies, and tried to build their own 19" racks. They ended up as being rather roomy, the power supplies almost fell down.
It was tracked down to the mechanics having calculated the metric equivalent of 19" on the old Norwegian inch of 25.6 mm, rather than the American 25.4 mm inch. 19 times 0.2 mm = 3.8 mm. Not terribly much extra, but enough to require some extra care for the power supplies to be securely fastened.
(According to Wikipedia, the SI inch definition of 25.4 mm was almost ten years old at the time, but it takes much more than ten years to change tooling and conversion factors. (And I am not going to bring up metrication in the US of A to prove my point.))
|
|
|
|
|
Surely most of these problems can be circumvented by using sensible variable or parameter names, eg AngleInRadians", "ElapsedTimeInMillisec" etc? Saves a lot of coding time, and however you try to avoid it, if a developer is determined to be dumb, he or she will be, whatever.
|
|
|
|
|
For me, C# lacks the easy way of custom types provided by Object Pascal, especially limited-length strings/etc. like
type
ShortStr = string[255];
TTextBuf = array[0..127] of Char;
TElfWordTab = array [0..2] of Cardinal;
|
|
|
|
|
|
Edited: The original Subject here was 'The Day I Learned to Hate the BOM'. After considering the first response, I have modified it to reflect a more appropriate and less offensive title.  I'm only explaining this to provide context for the first responder's grievance. (and strike tags are not allowed in the subject)
I've been importing text files for over 20 years and I thought I'd seen it all!...CSV lines enclosed in double-quotes, CSV fields with commas (not enclosed in double-quotes), implied decimal places, packed decimal format, subtotal lines, total lines, garbage lines, etc.
What I haven't seen before now are text files with byte order mark (BOM) characters that don't seem to do anything significant except to require dealing with.  It's probably been an issue long before now, but 90% of the time, the files have a header row so it wouldn't have mattered.
For fun, or as an office joke, you can add BOM to your own text files by changing the Encoding in NotePad.
"Go forth into the source" - Neal Morse
"Hope is contagious"
modified 17-Sep-23 11:32am.
|
|
|
|
|
Is that the same day as you saw BOM for the first time?
What is wrong with BOM? That you don't want to see it at all? That for this specific file, it "isn't needed", because all it contains is 7-bit US-ASCII?
You may of course declare that "I handle 7-bit US-ASCII only, so don't disturb me with anything else - Unicode is not my business, even when the characters are limited to US-ASCII. Just bug off with anything else!"
Fair enough, but then the software you produce is not for me. Most likely not for very many people outside the English speaking world. You are most certainly expected to handle BOM and Unicode/UTF8 today. If you are handling CSV, your are supposed to understand that in major parts of the world, it is five comma three, not five point three.
For the other stuff you mention: Fair enough; that should be easy to handle. If you haven't yet discovered that there are lots of variations in CSV formats (e.g. they are certainly not always comma separated, like in cultures where the decimal separator is not the point), take a look at the import options in Excel: It has handled this stuff for at least 15 year - I'd guess a lot more. Accept reality as it is, not as if reality was a problem.
And so on. You are free to put up a sign at your door: "Warning: No non-American data is handled by our software!" Actually, I'd be happy to know in advance, rather than discovering after I have signed a contract.
|
|
|
|
|
Thanks for the reply and for allowing me to realize that I had mis-titled the thread. I understand that the word 'Hate' was inappropriate for a number of reasons, firstly because I despise that word, and secondly because of your point about reality.
In my defense, the 'problem' had already been dealt with, (code fixed, tested, compiled, tested, and deployed) for the two affected imports before I made that post. I was simply annoyed about spending that hour diagnosing and fixing something that I'd never seen before...weird characters trashing the first element in a csv. 
Per your post, I had a few ways to deal with it, now having a crash course in BOM:
0: Tell the customer that they would have to change the encoding. (put up a sign) The customer gets these data files from other departments/systems. To change the encoding is would likely be a manual process. Not ideal at all.
1: Be aware that a text/csv file might have those three weird characters at the beginning of the file. If so, disregard the BOM and move on.
2: Go into full research mode and discover all that there is to know about BOM and how it might be needed for all of my non-US customers. (current/future === none)
I chose option 1. The reality is that I have to deal with it. The chances that I get a file from a US customer that is BOM encoded, and that does not have headers, and where the first element of the line is important have become realized. I didn't account for the BOM and got 'bitten'. 
Anyhow, my customer is happy again. I've learned something new and improved my software.
One of my favorite things about this profession is the constant learning and improving.
"Go forth into the source" - Neal Morse
"Hope is contagious"
|
|
|
|
|
The only thing to hate is hate itself.
|
|
|
|
|
|
"UTF-8 BOM considered harmful." 
I'm assuming you're talking about UTF-8. Including a BOM with UTF-8 is generally unnecessary and frowned upon in most cases.
I'll have to review my latest text file reader to see what I do with them -- one I wrote earlier this year would ignore a UTF-8 BOM if it was the first three bytes of a file.
In general, a file should have only one encoding, but there is no requirement for that to be the case. If a file switches between encoding, then I believe a suitable BOM must be used to indicate that. But good luck finding a reader which will honor such an abomination.
When this sort of thing is more likely to be a concern is when reading from a non-file-backed stream such as a socket -- but I would expect that other controls would be put in place to avoid confusion.
Now I need to go create a CSV file which is UTF-8, but with a UTF-16 Word document as one of its values...  (muhahaha!)
|
|
|
|
|
Yes, I depended upon some code I was writing at jsfiddle.net and suddenly the entire sample code was gone.  I had worked on this for a few days. Oy!! PaNIC!! PANIC!!!
Here's a snapshot of the fiddle that exists and doesn't exist[^].
You can see that JSFiddle is generating a snapshot of my original code (on the right).
But, how can I see the code, but it isn't there!?! PanIC! p-p-p-PANIC!!!!!
However, if you click the jsfiddle then the system attempts to load the editor and everything is blank. Here's the link to the fiddle[^] -- which is blank.
!!!!
If you compare the link to the image you can even see that it is referencing the 72gzs94v ID that is supposed to be the code.
The code exists and it doesn't...
Got Very Lucky
I was able to inspect the code from the original snapshot and copy out the code using FireFox web tools so I didn't lose code that I had worked on for quite some time.
I no longer trust jsfiddle (and yes, I was a fool for trusting it in the first place.)
Public Service Announcement
Trust no one! Always save backups!! 
I now have a backup of the code on my local machine. Phew...
|
|
|
|
|
You're missing the version suffix on the path. As far as I can see, the last version you saved was #74:
Edit fiddle - JSFiddle - Code Playground[^]
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
So fantastic!!
that's one of the reason I post these crazy things to CP...because there are so many smart and helpful people here.
Absolutely amazing you noticed that!!!
I wonder why that it wouldn't load that from my JSFiddle.net account??
Thanks so much for reading my post and for your help.
I really appreciate it.
EDIT
And I should say this too. I logged into my account from another web browser and it still failed.
Then I logged in on another machine and it failed too.
Must be a crazy bug in the JSfiddle account plugin.
|
|
|
|
|
|
One of the great mysteries of the web:
Once you put something on it, it exists forever... somewhere.
Until of course you need it again, and then it no longer exists anywhere.
Both of these statements are true simultaneously, of course.
Software Zen: delete this;
|
|
|
|
|
It's like the old monkeys on typewriters story. Every document, image, etc is out there somewhere. It just hasn't been indexed yet.
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
|
|
|
|
|
Gary R. Wheeler wrote: Once you put something on it, it exists forever... somewhere.
Until some suit decides to delete it thinking that will boost their site's SERPs: 
CNET Deletes Thousands of Old Articles to Game Google Search[^]
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
JS fiddle is awesome. I use it on the regular, but if you're tinkering with server-side or isomorphic JS it's much, much safer to just run it via node directly on your machine. Even for really simple stuff, it's command line interpreter will things perfectly. Just as long as you don't need a DOM or styles for your quick and dirty testing.
Jeremy Falcon
|
|
|
|
|
Attempting to set up User Isolation on a IIS FTP on Server2022 so I can test a FTP Client I wrote.
I was expecting it to create a new user directory under FTPRoot when I logged in.
No dice.
Found some documentation.
FTP User Isolation <userIsolation> | Microsoft Learn[^]
Then I found this chart. It actually uses SPECIFIC path that must exist or you get the error:
530 User cannot log in, home directory inaccessible.
Login failed.
ftp>
User Account Types Home Directory Syntax
Anonymous users %FtpRoot%\LocalUser\Public
Local Windows user accounts (Requires Basic authentication) %FtpRoot%\LocalUser%UserName%
Windows domain accounts (Requires Basic authentication) %FtpRoot%%UserDomain%%UserName%
IIS Manager or ASP.NET custom authentication user accounts %FtpRoot%\LocalUser%UserName%
See a snapshot of this chart[^].
The 3rd one was the one I needed. It is strictly incorrect.
If you were to expand those environment vars as they are you'd get: MyFtpRootCompanyDomainMyUserName
It is supposed to have directory separators between them.
Like this ==> MyFtpRoot\CompanyDomain\MyUserName
Filed under weird (and annoying / bad documentation).
|
|
|
|
|
I thought FTP died. Wasn't there a memorial service for it in the mid aughts?
*hides*
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
