|
charlieg wrote: Every engineering system should be in metric. Period. If you want to convert something to English - that's a presentation issue,
totally agree with that.
And I add...
Little vs Big Endian and similars. --> I have spent some time when looking for errors until I got used to make the check of inverting the significancy of the bytes when starting to work with two different systems I hadn't configured myself.
Signed vs unsigned values (most significant bit as the sign) --> You get to 32646, 32647 and then you see -1, -2, -3...
PLC String vs PC String --> PLC needs 2 bytes more "total length" and "used bytes" of current content (1st letter is String[2] position), having to transform to Array of Bytes to communicate
...
there are a lot of "funny" error sources out there
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
modified 27-Sep-23 15:21pm.
|
|
|
|
|
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;
|
|
|
|
|
|
IIRC that's part of the original Pascal specification. When I started with C# (corporate edict) in about 2003/4 that's the first feature I missed badly.
|
|
|
|
|
It seems like the sample the author provided is overkill for the passing of 3 simple variables.
What is the purpose of any of this, I have no idea, except to make programming more confusing to the developer.
What is wrong with passing a well-named variable as a primitive, especially with the hardware we work with today?
In any event, I use Structs\Structures to pass data and Classes to execute methods. However, unless there was a specific reason to pass certain data in a Struct\Structure (ie: such as the need to pass all of the data, which makes up a particular Struct\Structure, passing such data as individual variables makes a lot more sense then wasting time on creating Structs\Structures to do so...
Steve Naidamast
Sr. Software Engineer
Black Falcon Software, Inc.
blackfalconsoftware@outlook.com
|
|
|
|
|
To be fair, this was the beginning of the example, but the main thing you get is the compiler can check the type and warn you that you are using the wrong type.
This also means the code is quite a bit more explicit about what it wants so a future dev who may have thought, "hmm....wonder why orig-dev wanted a double when a float would do" would be guided away from such a thought since there is a specific type.
That's all I got. 
|
|
|
|
|
Orig-dev could/should have provided a comment if choice of the primitive type was significant.
"Keep it as simple as possible, but no simpler".
Many developers have a tendency to introduce complexity for the sake of it, because it looks clever, it's an interesting exercise, or other similar reason, when it achieves little but obfuscation.
|
|
|
|
|
I once worked with a programmer 28 years ago who was approaching retirement. We worked on an accounts receivable/payable system together. He did all of the backend calculations in exactly the same format as step 1. If I remember correctly even his function names were single letters of the alphabet. I think I would have done at least step 2. I thought it was the simplest code you could possibly write. Back then there was no intellisense so we just documented our code thoroughly! I don't see any value in step 3 or 4. Seems like unnecessary layers of code.
|
|
|
|
|
John Chadwell wrote: I don't see any value in step 3 or 4. Seems like unnecessary layers of code.
You have much experience also and most likely that means you have developer discipline (do things right the first time so you don't shoot yourself in the foot later).
Developer discipline doesn't seem like it is being taught in modern times -- probably influenced by dynamic languages like JavaScript which also encourage people to "type" code (not design it and write it).
So, for this modern world i believe the movement is to "put the discipline in the code" so those who come after are "forced" to use it the way we have designed it. In the past, we would've read the legacy code and kept the parts that seem right.
Also, this is just the latest shiny. 
|
|
|
|
|
Complete Novas HERE
When I look at Wrap All the Primitive Types In Structs
This looks logical to me ?
That said it took me a little time to learn to use {get;set;} example below
so my question is this code structure a good design or as stated just a fancy new way to write your code
If this is considered a programming question sorry just delete the post. I try to follow the rules honest
I did read all the replies
namespace CRUDLibrary
{
public partial class frmCRUD : Form
{
public static string dbName = "Contacts.db";
private string result;
public string fn { get; set; }
public string ln { get; set; }
|
|
|
|
|
Just curious where did you manage to get that book. Everywhere I search for it says it is pre-order to be delivered by the end of next month.
- Leonardo
|
|
|
|
|
Leonardo Pessoa wrote: Just curious where did you manage to get that book.
I'm a card-carrying member of oreilly.com -- ebooks from hundreds of publishers (manning, no starch, ms press, O'Reilly, Wiley, Addison-Wesley, -- to many to name) with 70,000 books available.
Most of the time the ebook releases before the book even releases and it is available on oreilly.com
You can try it for 10 days at this link (Create Your Trial: O'Reilly[^])
Disclaimer: I have no connection with oreilly and that is not an affiliate link.
The access to all 70,000 books and X,XXX number of videos is unlimited. It's quite amazing.
FYI - I've been a member of Oreilly since 2002 (when it only cost $10/month). It finally went to $19.95 / month and when they converted my account to their new system they let me grandfather into the old price $19.95 / month, but I know it is quite a bit more expensive now. Something like $39.95 / month or so.
|
|
|
|
|
I'm kind of against the whole "make your code more readable...at the cost of performance and efficiency". Programmers of the future who cannot understand the context of the past (and therefore the code) are of little concern. It might be that, as an engineer, my first stance is that all newcomers must be educated (a little) and eventually they should learn to educate themselves (a lot).
It harkens back to the guilds...but, except for being exclusive, there wasn't very much else wrong with their educational system.
So if someone wants to break OOP, they should write their own language and let everyone else be. I'm just happy I don't have to remember if that string of bytes was an integer or a floating point value (and I use the wrong mnemonic for multiplication). If you don't like inheritance, don't use it.
|
|
|
|
|
I agree with your answer.
Here's a reply I said to someone else that is about developer discipline related to this topic:
You have much experience also and most likely that means you have developer discipline (do things right the first time so you don't shoot yourself in the foot later).
Developer discipline doesn't seem like it is being taught in modern times -- probably influenced by dynamic languages like JavaScript which also encourage people to "type" code (not design it and write it).
So, for this modern world i believe the movement is to "put the discipline in the code" so those who come after are "forced" to use it the way we have designed it. In the past, we would've read the legacy code and kept the parts that seem right.
Just as you said,
Juan Pablo Reyes Altamirano wrote: my first stance is that all newcomers must be educated (a little) and eventually they should learn to educate themselves (a lot).
Unfortunately, there seem to be people moving into Software Development that just think they can start typing and produce a program.
|
|
|
|
|
raddevus wrote: probably influenced by dynamic languages like JavaScript which also encourage people to "type" code (not design it and write it).
I can't even remember how many of my sequential programs were born on a DIN A2 paper where I draw everything with pencil, moving coins to simulate the value of the states and then playing with the possible permutations of the transistions.
Specially when timing / synchronisation of different systems were needed.
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
I would not say it's a new concept, DDD introduced the concept of value objects a while back. Strong typing a value is how many implement value objects in C#.
The logical continuation for this concept should be:
1- Add validation, what is the specific range of value that are acceptable to your function. In your example, should you accept a speed of 62123.25?
2- Add units, is it always the same unit, or should you convert from different units?
3- Displacement, Angle, Speed are very vague, are we talking about vehicles on a public road? or a spacecraft? Maybe we should use VehicleSpeed instead?
4- Maybe VehicleSpeed should derive from a base Speed class so you don't repeat units and conversions all the time? But you could add validation of acceptable speed value for a vehicle?
And we're back to the good old OOP. Should you calculate the Displacement in the VehicleSpeed class? I don't think so, this should be composition, but the encapsulation of the speed value, it's units and validation into a class is definitely desirable.
It is a question of perspective. We tend to work with good enough, but if you want accuracy, I would debate that those are the things you NEED to do.
The reasons why most of us don't go the Value Object route are: That's a lot of work. It takes time, we're in a hurry, it makes code base bigger, some would say more complex (I disagree).
Is Primitive Obsession a code smell? I say YES! But are we willing and able to do everything that is required to REALLY fix it?
Christian
|
|
|
|
|
Very interesting points...and you should read that book, because that is exactly the angle the author is taking. Chapter 1 was very good, challenging and interesting and has definitely changed my mind on many things. I think using these ideas at the right time will make better code.
Just started chapter 2 and it is continuing to be interesting so this is a really great book bringing together a number of interesting ideas.
|
|
|
|
|
I'm sure there are some good points, and that many of my objections may be only because such simple examples are provided, but as presented it rubs me the wrong way. I'm sure the author isn't saying "do this all the time".
I am unlikely to create a single-field or -property class or struct without also adding Methods. At least a custom ToString. Or make it IComparable to itself. Then there is some actual benefit.
My experience hasn't needed such things, but I could see separate structs for OunceTroy and OunceAvoirdupois, for instance. Yet I would not want to see someone making a struct for each time zone (use DateTimeOffset for that).
Two thoughts:
0) It looks like it can lead to a form of Hungarian Notation, but one with compiler support and protection.
1) If not C#, maybe another language would use this type of thing to provide compile-time safety, but decompose such simple structures to the underlying primitive types for improved speed. Maybe at JIT time?
|
|
|
|
|
While I can see the value in some corner cases perhaps, I feel like the acceptor, such as a parameter name on a method should describe what it accepts.
Maybe it's just because I grew up with that, but putting the units for example, on the data type itself seems just ... unusual, and kind of awkward to me.
Maybe that's not the best argument against it, but I place a lot of value on being able to lean on habits, so long as the habits aren't actually counterproductive. All else considered equal, I place more value in doing something in a way that's supported by "muscle memory" than I do on implementing something perhaps in a more formalized way, and the reason is, if you can lean into your habits, as long as you develop decent habits you get less bugs and more productivity.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
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.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
