|
Nicolas Dorier wrote: Unicode 8207 was not the '/', that's the reason why the two length were not the same. The Unicode character system is a set of bits that when cobbled together become the symbol of a character that is represented. Another way a set of bits can be cobbled together become the symbol of a character. In the same way, a Unicode character can be represented as a number. However that character can reach into the millions as a number.
In order to represent a character or number on the screen a graphical image must be displayed. That means it has to have software that when given the number displays the right graphical image. An ASCII character MUST be one byte long, no more, no less. IE it requires 8 bits to represent a character. In ASCII, a zero is equivalent to SQL's NULL and isn't a character, so ASCII can only have 255 characters. I don't believe the ASCII set of defined characters has a length of 255 in it. So, depending on the software, the image displayed can change between the devices. Unicode is a character that uses at least 2 bytes and up to 4 bytes, which means it could have a character set that is 4 billion characters long.
We're nowhere near that level, like I said, I believe the length is around a million. As far as "a" is concerned, this is an ASCII character and a Unicode character, there isn't a hidden character involved. One uses one byte and one uses two bytes. The application software supports enough graphical design to support both versions of "a" and I believe because of that it only counts the length as 1 even though it is using two bytes because it is accounted for in software.
The 8207 is the character that has a graphical image of "/" in some software, but when it runs in code it looks exactly like the special 'a' character using Console.WriteLine. It isn't a hidden character, both times it re-reads 8207, so both times it reads the exact same location twice. It's a screw-up in how it counts so even the left/right arrows read the same location twice. In that respect, yes, it is a hidden character.
|
|
|
|
|
The 8207 is the character that has a graphical image of "/"
You are wrong this has nothing to do with "/"
Here is the same bug without "/" but with 8207.
String str1 = "test";
String str2 = "test";
Moreover, a char is not ASCII but a 16 bit unicode character, contrary to C/C++.
|
|
|
|
|
Yep. Your "a"'s are ascii 97 and Unicode 1072. Interesting, the second one also exceeds 1 byte, but still counts as one character. (2^10 is 1024, so it takes 11 bits, 2^3 is 8 so the "/" longer character takes 14 bits. You are absolutely right that debug makes it look like the / character is too long to display the interpretation.
|
|
|
|
|
it is not related to the "/" but the unicode char 8107 that you can put where you want. (see my previous comment)
|
|
|
|
|
var scheduleContacts = Engine.APIProxy.GetAllCompanyInfoContactScheduleContactsByCompanyInfoContactScheduleHeaderId(schedule.Id);
That is a REALLY long method name.
If it's not broken, fix it until it is
|
|
|
|
|
Good one.
This is taking the suggested C# naming conventions a bit far, but I do think it is better than
var scheduleContacts = Engine.APIProxy.GetAllCmpnInfCntctSchdlCntctsByCmpnInfCntctSchdlHdrId(schedule.Id);
Soren Madsen
"When you don't know what you're doing it's best to do it quickly" - Jase #DuckDynasty
|
|
|
|
|
Probably someone taking the Aggregate Root concept to the extreme.
Also, a horrible use of var.
|
|
|
|
|
Vark111 wrote: Also, a horrible use of var.
I know what you mean!
List<CompanyInfoContactScheduleContactsByCompanyInfoContactScheduleHeader> scheduleContacts = Engine.APIProxy.GetAllCompanyInfoContactScheduleContactsByCompanyInfoContactScheduleHeaderId(schedule.Id); would have been so much clearer!!!
|
|
|
|
|
How about stating it as below
GetAllCompanyScheduledContactInfo(schedule.Id) or
GetAllCompanyScheduledContactInfoByScheduleID(schedule.Id)
Thanks,
|
|
|
|
|
Steady on there.....should be simply;
var results = Engine.APIProxy.GetResults(...);
|
|
|
|
|
Ranjan.D wrote: ...GetAllCompanyScheduledContactInfo(schedule.Id) or...
The problem with that is that you don't get to get even for outrageously long names by making them even longer and more confusing.
|
|
|
|
|
That's somebody who doesn't like comments. He or she has bought into the idea that code should be self commenting.
|
|
|
|
|
That's kind of the opposite naming principle to my examples below.
Nearly as bad.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
Nothing wrong there. It is not like you are going to type it.
|
|
|
|
|
The longest one I have seen was about 1000 characters long. Abbreviated. With a Namespace of ~1300 characters (excluding the '.') and a class name of ~700 characters.
I remember this as I was going to use the library this was in. I quickly decided to use a different library instead (this library had a whole host of other things that would belong here, if I could remember the name of the library [it was a weird, unpronounceable, seemingly randomly generated name] I would post a link to it.)
What do you get when you cross a joke with a rhetorical question?
|
|
|
|
|
What a stupid beginner! What does Engine mean? Is that a ApplicationProgrammingInterfaceProxyEngine ? That's still not meaningful enough. And that APIProxy , that also needs a better name! I cannot understand that line of code because of that bad naming.
|
|
|
|
|
What the developer really meant to do was:
var scheduleContacts = Engine.APIProxy.GetAllCompanyInfoScheduleContacts()
.Where (p => p.ScheduleHeaderId == schedule.Id)
.OrderBy (p => p.CompanyInfo);
/ravi
|
|
|
|
|
Looks like someone has just read something about Domain Driven Development and was fiddling around a bit. 
|
|
|
|
|
This one speaks for itself...
Private Sub LoadGrid()
Dim SQL As String
Dim x As Long
Dim rst As New ADODB.Recordset
txtMode.Text = mode
txtPID.Text = PID
txtPolTypeID.Text = policytypeid
x = Val("" & txtPID.Text)
End Sub
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
Part of my job is to write stuff in MVC, c#, Sql, etc.. and replace our outdated systems. Doing this requires supporting the older legacy stuff until I can replace it.
I'm currently writing a program that is very important to our company. The task I have now is to get some data out of this system and move it over to a database (in access). I can't skip this database (yet) because so much stuff works off of it. No big deal, the goal is to get rid of it, but for now just xfer some data so everything can function as per normal.
62 columns. The "main" table in this database has 62 columns. Lets not get started on data types, misused fields, etc. So I figured I'd just power through it. Nothing to do, it has to be done. Well, then I get a field to small error. Now I have to debug it.
So terrible structure aside, the "control" copy of this database (we have a new instance per client) has a definition for said field that is unstable. It's one that needs to be changed per use to fit the data that's being inserted. This isn't documented anywhere.
I'll be glad when I get this finished so I can move on.
Elephant elephant elephant, sunshine sunshine sunshine
|
|
|
|
|
First I've heard of that. Should I send some tequila over?
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
From the classic VB project I'm porting...
Dim FirstTime As Boolean
Dim FirstTime2 As Boolean
If FirstTime = False Then
If FirstTime2 = False Then
End If
End If
There's nothing like good clear variable naming.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
...and that's nothing like good clear variable naming.
Did you string the coder up by his thumbs?
You looking for sympathy?
You'll find it in the dictionary, between sympathomimetic and sympatric
(Page 1788, if it helps)
|
|
|
|
|
I wish I had the option - developed by an external party, I'm glad to say we've moved development in-house.
Actually, in spite of all these horrific examples I keep posting, I'm charged with redeveloping from VB6 to .NET MVVM architecture - I'm lead developer on the project, so have tried (as far as possible) to introduce good practice.
There are still issues - the database we have to access is as bad, if not worse, than the VB code (many tables with no PKs (at least until I add them the first time I have to touch it), triggers doing insane things, and tables with names TCMPCOMMABSOLUTE (which stores insurance policies), but at least we can slowly get things working in a sane manner.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
Do you have database tables that are called something like "ZZZZZZ_tblYNManualDELETE"? I have no idea what this table held because it's contents are a bunch of gibberish, but I can say that the application never touches it. I think...
Or touches the 35 or so other tables with similar naming "conventions".
|
|
|
|