|
We had similar fun with dates:
* When an ICL 1900 booted up, its Manual EXEC asked for the date. The year format was two digits and was based at 1900 (unlike the operating system that took two digits where 65 to 99 were 1965 to 1999, 00 to 64 were 2000 to 2064). One operator entered the full year (e.g. 1982) and the Manual EXEC took the first two digits (19) as meaning 1919. That worked fine - dates for files and exofiles (data on disks not included in the operating system's filestore) were updated with dates representing 1919. When the machine was rebooted again, the next operator correctly entered the year as 82. This caused all of the files to be deleted as they were 63 years old - way outside of their expiration period.
* On an ICL SYSTEM 25, the boot sequence expected (IIRC) a date in the format nn/nn/nnnn. It then prompted the operator with a message like 'Today is Sunday. Is that correct?'. The operator had entered 01/11/1981 which was a Sunday in dd/mm/yyyy format [1st Nov] and was also a Sunday in mm/dd/yyyy format [Jan 11th]. The prompt gave the operator confidence that he had entered the date correctly, but he hadn't used the correct format.
|
|
|
|
|
string MyName => SomeOtherName;
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
Don't worry, it's just a temporary thing. Next migration will change the database column names and (dis)order will be restored in universe. 
Mircea
|
|
|
|
|
So, I smiled when I read this, thinking of the because it's easy and makes sense answer.
But really, this is a deeper question that depends on what language you are using and what the application interaction with the user is. I'm assuming you're comparing local variable names to the DB columns; and not accessing the actual DB object.
There are cases where this may not be best practice and maybe a case could be made to argue it is not best practice at all.
|
|
|
|
|
I assume you're not using an ORM? All the ORM's I've used (EF, Linq2SQL, Dapper, etc) have the ability to attribute the model with table and column aliases.
|
|
|
|
|
But why one should use different names? Is it not only make the things more confusing?
|
|
|
|
|
Job insurance. 
|
|
|
|
|
Because the people that once designed the database gave their columns names like cicmpy (customer info company, or something like that, taken from a very popular financial system).
Or because you're dealing with TextField1, TextField2,... TextField20, DateField1, DateField2,... DateField20, etc. "because the software should be flexible." (I have to admit, the software is flexible and works miraculously well, but their API is horrible).
|
|
|
|
|
0x01AA wrote: But why one should use different names?
Certainly one reason is that databases have absolute length limits. So if you exceed that you are out of luck.
As an example the Oracle column name length limit is 30.
Additionally when database statements are constructed there are length limits on the total length of that.
One of course should not normally run into that. Which is perhaps worse because what happens is that someone uses magical coding APIs without understanding what is actually happening and then when it fails for that one odd ball case then no one can figure out what is happening.
Then there are things that happen over time. Such as a table that has a column named 'total' which even though the column is still named that, what is actually is now is the 'DailyTotal'. Column might be used in one place where in the code the attribute 'DailyTotal' is used in many places. So explaining what it actually is in every place becomes a problem.
|
|
|
|
|
jschell wrote: As an example the Oracle column name length limit is 30.
Our company was working on a new coding standard, and the editors proposed a max line length of 80. The problem was that we had rules for how to construct (a certain class of) #define constants, that frequently lead to constant names exceeding 80 chars in length 
I tend to associate any system that limits identifier lengths with Fortran II and the 1950s. We should have come further today! (I know that we haven't, at least in quite a few areas.)
I tend to associate any system that won't accept identifiers of distinct, independent objects (such as files, network nodes etc.) containing spaces, æøå or other extended alphabetic character, with Unix / Linux. (I know that the core accepts more than a-z0-9, but that's of no use when *nix applications do not! Linux application naming restrictions is a major reason why I dislike working with Linux.)
|
|
|
|
|
trønderen wrote: I tend to associate any system that won't accept identifiers of distinct, independent objects (such as files, network nodes etc.) containing spaces, æøå or other extended alphabetic character, with Unix / Linux.
So?
Programming is not of course the universe but rather a subset. So limitations must exist.
I suspect the reason for spaces at least goes back to command line usage.
Look at the problem with windows which does allow spaces but which does not recognize case sensitivity.
trønderen wrote: æøå or other extended alphabetic character
Not exactly sure about that one. It was my understanding that if your OS, all the major ones, was properly upgraded to the culture setting then it does support the characters appropriate to the culture. But if I am working in US English then I do not want to see those characters in the file names.
Using a full Unicode character set has performance and data size implications. So although I might create a database field that supports Unicode for a user entered value, the text columns that are specific to the application will not be using Unicode.
|
|
|
|
|
jschell wrote: So limitations must exist.
A great argument for any arbitrary limitation (when you don't have any other good justification).
No, forbidding spaces "must" not be a restriction. We have had computer systems allowing it since the 1970s. (I saw it first time in a Xerox document processing system around 1979. Not only did it allow spaces, but file names that were a line long, like "1975-04-12 Letter to Jim Jones" - at that time, *nix file names was limited to 14 characters, DOS to 8+3.) Practically speaking all desktop PCs have had OSs and file systems allowing it for 30+ years. There is nothing in the *nix file systems forbidding it either. The problem is that application writers in *nix environments work under self-imposed restrictions, to make the programming easier for themselves.
I suspect the reason for spaces at least goes back to command line usage. Nobody justifies limitations on programming practices by referring to assembly programming environments, or use of magnetic tape. Why should a programmer refer to a CLI environment as a justification for limitations in a modern screen oriented environment?
Look at the problem with windows which does allow spaces but which does not recognize case sensitivity. I am really happy that the DOS/Windows file system designers made that deliberate design decision. In all my traditional, non-PC, writing, upper and lower case have no semantic difference. A file name is semi-external to the PC itself, it is not internal like a source program but displayed to non-computer-people.
Case sensitivity seems to be another "let us make it simpler for ourselves". Of course it takes a little programming effort to handle case independence (just like with spaces in names), but it gives the end user what is most natural to him/her. Also, comparing for absolute equality with no conversion makes it easier to win the performance race.
But if I am working in US English then I do not want to see those characters in the file names. Will you accept that the Asians have the same attitude towards Latin script in file names? You won't even accept my Norwegian file names and URLs, is that so?
Using a full Unicode character set has performance and data size implications. There you have it again: We cannot provide the user with what (s)he wants/needs, because it would reduce our chances of winning the performance race.
There is no inherent data size limitations (call it 'implications' if you like). Either you handle arbitrary length strings, or you have a limit even for 7-bit ASCII. Besides: Storing English text as UTF-8 has very low space overhead.
Are you aware that Windows does not use 32-bits Unicode internally? It halves the space requirement by using UTF-16. Not too many years ago, every single language for which a written form was defined could fit all their characters into a single UTF-16 code. Having to resort to escapes is a very rare (and quite recent) situation.
the text columns that are specific to the application will not be using Unicode. So you will not prepare for porting your application to other cultures. As you refer to text, even if the other fields are not 'user entered', I guess that they are terms that may be appear e.g. as headings, or as month/weekday names, product categories or whatever. For internationalization, it is not sufficient to handle national characters in user specified strings only.
|
|
|
|
|
trønderen wrote: A great argument for any arbitrary limitation (when you don't have any other good justification).
I am old but not old enough to have worked on some of the very first OSes which then lead to the PC OSes.
I do know that PC/MS-DOS did not allow spaces in names.
I also know that using spaces in command lines (Unix, linux, MS/PC-DOS, early windows) either did not support spaces in arguments at all or required special handling. From that it follows that the possibility exists that file/directory names with spaces would not have been ideal.
trønderen wrote: No, forbidding spaces "must" not be a restriction
I didn't say that.
trønderen wrote: to make the programming easier for themselves.
No idea what your life is like but in my life I work for businesses. And the goal is to produce applications that meet many of the needs and desires of customers. But only when it is cost effective to do so. So even if one customer wants something specific unless they are willing to pay for exactly that (and that almost never happens) and unless it does not unduly impact the maintenance (ongoing cost) and other customers they do not get it.
I have seen not indication that that has not been true for far longer than 30 years.
trønderen wrote: I am really happy that the DOS/Windows file system designers made that deliberate design decision.
Just so you know Microsoft bought (licensed) an operating system when IBM approached them initially for their BASIC language to meet the requested needs of IBM. So certainly not Microsoft's fault.
trønderen wrote: Will you accept that the Asians have the same attitude towards Latin script in file names? You won't even accept my Norwegian file names and URLs, is that so?
That has nothing to do with what I said. Seems like you are even trying to denigrate me.
I have created and supported applications that are used all over the world. In Japan. In Korea. In Europe. Not sure about Norway but certainly in France, Germany, Italy and Finland. Even in Russian although I don't think we actually did an install there.
trønderen wrote: We cannot provide the user with what (s)he wants/needs, because it would reduce our chances of winning the performance race.
Another statement that makes me wonder if you work in business or academics.
Businesses do not exist to meet the needs/desires of customers. They exist to make money. Companies that don't make money do not survive. Every addition, even if it is a need/desire of customer(s) costs money. Both to implement it and to maintain it.
Yes performance is important. It is something that customers always complain about (when complex applications are involved). And it is something that marketing and sales promotes all the time.
trønderen wrote: Not too many years ago, every single language for which a written form was defined could fit all their characters into a single UTF-16 code.
See prior comment. I have written and supported applications that run all over the world. I have led initiatives to make large applications multi-lingual.
So yes I am quite familiar with both what Unicode allows and what it costs to implement, support and maintain.
trønderen wrote: So you will not prepare for porting your application to other cultures
You apparently did not understand what I was referring to.
In large applications there will be character data that is internal to the application. It will never be exposed to users.
It has nothing to do with multi-language support.
There are two other types of character data.
1. Application data which is exposed to customers. Such as a column header on a report. Or a user error message. This is the category where localization of language support is needed and in its easiest form.
2. Customer entered data. Such as a the name of a street or a user comment. This is the category where the concept of localization of language becomes tenuous because something that is entered in France can only be displayed as is in Japan.
|
|
|
|
|
Prefix tables with "tbl" and your code be happy.
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.
|
|
|
|
|
Q. What do you call a bear with no teeth?
A. A gummy bear.
|
|
|
|
|
Q. What does a 400lb bear eat?
A. Anything it wants.
I'll just grab my coat and see myself out.
PartsBin an Electronics Part Organizer - An updated version available!
JaxCoder.com
|
|
|
|
|
Should've went with gummy bears. 
|
|
|
|
|
Yeah, but it was already taken.
I could have went with;
Out in north west US they have grizzly bears, which are a very ferocious beast so they make all the hikers wear small bells around their necks to scare the bears away.
You know how you can tell a black bear from a grizzly?
Grizzly poop has little bells in it.
PartsBin an Electronics Part Organizer - An updated version available!
JaxCoder.com
|
|
|
|
|
No no.... he eats gummy bears.
Ah well, I've got nothing.
|
|
|
|
|
They do the same in Japan except the explanation is so you let the bears know you are approaching, a startled bear apparently is rather dangerous.
Thankfully Oz only had drop bears.
Never underestimate the power of human stupidity -
RAH
I'm old. I know stuff - JSOP
|
|
|
|
|
A couple of old ones
Even if a bear wears socks and shoes he still has bear feet.
A bear walks into a bar and says,
“Give me a whiskey and ................cola.”
“Why the big pause?” asks the bartender. The bear shrugged.
“I’m not sure; I was born with them.”
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
What do you call a dog with no legs?
It doesn’t matter - it’s not going to come anyways!
If you can't laugh at yourself - ask me and I will do it for you.
|
|
|
|
|
I keep finding methods that seem outdated and/or don't have all the functionality I need.
I'm using vb.net in VS 2017. The webcam is a Logitech Brio.
I need the ability to take still photos, and acquire video. In both cases data from another source will be overlaid in the image, as it is recorded.
Any suggestions would be appreciated. Links to examples/demos would be great too.
thanks!
|
|
|
|
|
Wrong place to ask: see the sentence above that ends in red. Then try here: Ask a Question[^]
But ... tell us what you tried, exactly - and what happened when you did. That way, we don't waste our time or your time giving you "solutions" you have already rejected ...
And see here: Asking questions is a skill[^]
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Turn it on.
Face camera.
Was it really that hard?
I’ve given up trying to be calm. However, I am open to feeling slightly less agitated.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
