|
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".
|
|
|
|
|
Lucky bastard...
We just finished the porting of an AS400 DB, where table names were T123P3 and column names were C23A1. The one designed it dead years ago and we had to read table-table to figure out what the table for. We got some help from an application we could run against the DB, but took over 8 months to identify all tables and columns...And just for the fun - the DB was as far as it can be to be normalized...
I'm not questioning your powers of observation; I'm merely remarking upon the paradox of asking a masked man who he is. (V)
|
|
|
|
|
Maybe not so lucky. A lot of data is in columns with names that may be worse than cryptic. These names are just downright deceiving, like "LpkEngineeringPeerReviewName". Seems like it would hold the name of someone doing some kind of peer review, right? WRONG! It stores the type of installer a piece of software uses, in plain text, like "Automated MSI w/MST".
Nearly half the fields in the entire database are like this. It took me about 6 months to map every field to what it really contains and write importers for everything I needed.
|
|
|
|
|
Ah, that's something an old colleague called "repurposing" - rather than change a column name, the column is "repurposed" to be used for something entirely different.
What could go wrong?
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|