|
short variable names are always a blessing.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
sounds like the kind of thing you'd get from a machine-ported app.
i worked at a place that had some C code which did quadratic optimization. but nobody could make any sense of the C, because it had been machine-translated from FORTRAN - all the variables were "a", "b", "c", etc., and the code was full of GOTOs and statics.
we eventually bought a C# implementation.
|
|
|
|
|
sadyly, it was hand-written - I know the professor that wrote it. All of his programs are written that way.
|
|
|
|
|
A place where I used to work had a lot of code with variable names like a, aa, b, bb, etc. Their reason? The time they saved by not typing out a longer variable name would add up to a significant time savings over the course of a year. They also saw nothing wrong with method names like "DoIt".
You think that these things would make the code to understand? Their answer to that objection was "A good programmer can figure out what the code does!".
I don't work there anymore, for obvious reasons .
|
|
|
|
|
a while back I visited a web site that gave me a javascript error on load.
curious, i looked at the page source. The function with the bug was named "JoshIsCool"
|
|
|
|
|
Yeah, Josh is so cool that his javascript won't even load
Bill W
|
|
|
|
|
Steven A. Lowe wrote: BB21
Is he a fan(atic) and lunatic user of Microsoft Excel (spreadsheet program) which has this AA, BB type arrangements for its grid?
Vasudevan Deepak Kumar
Personal Homepage Tech Gossips
All the world's a stage,
And all the men and women merely players.
They have their exits and their entrances;
And one man in his time plays many parts... --William Shakespeare
|
|
|
|
|
No, actually he's a Mac fan, and the program in question is older than spreadsheets...
|
|
|
|
|
Hey...
I resemble that remark.
Andrew
|
|
|
|
|
Real men don't need variable names! Real men use memory addresses!
To those who understand, I extend my hand.
To the doubtful I demand: Take me as I am.
Not under your command, I know where I stand.
I won't change to fit yout plan. Take me as I am.
|
|
|
|
|
I am refactoring a project that has basic unit conversion stored in a sql database along with everything else. Each time a business object gets loaded from the database, a separate call to the database is made to get the 3 units that belong to the business object.
When is the last time any of these natural conversion has changed? Are they suddenly going to change the amount of milligrams in a gram, or pounds in a ton?
If there were any conversions that were irregular like grams in a case or something like that, I understand, but for the natural conversions? The worst part is this database is almost always called over a VPN connection, so bandwidth is critical. The previous programmer could have at least cached the data on the client side or something...
|
|
|
|
|
Today's lesson is brought to you by the word "niggardly". Remember kids, don't attribute to racism what can be explained by Scandinavian language roots.
-- Robert Royall
|
|
|
|
|
|
Netblue wrote: The previous programmer could have at least cached the data on the client side or something...
But that would make sense!
|
|
|
|
|
Do they happen to be storing the current time in the database as well?
|
|
|
|
|
I think there is a webservice call for that one...
|
|
|
|
|
lmao
To those who understand, I extend my hand.
To the doubtful I demand: Take me as I am.
Not under your command, I know where I stand.
I won't change to fit yout plan. Take me as I am.
|
|
|
|
|
How many ounces are in a pint?
|
|
|
|
|
IF your lucky 20, if your in the states typically 14, unless your local pub has the good glasses that allow a full 16 with 2 inches of head.
|
|
|
|
|
You only get two inches of head?
|
|
|
|
|
Netblue wrote: The previous programmer could have at least cached the data on the client side or something...
That would have been nice.
Netblue wrote: The worst part is this database is almost always called over a VPN connection, so bandwidth is critical.
Is it possible to make any changes to that or are you stuck with it?
"The clue train passed his station without stopping." - John Simmons / outlaw programmer
"Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon
"Not only do you continue to babble nonsense, you can't even correctly remember the nonsense you babbled just minutes ago." - Rob Graham
|
|
|
|
|
Paul Conrad wrote: Is it possible to make any changes to that or are you stuck with it?
There are 8 locations connecting to a central site, VPN over the net. A better way to do it would be SQL replication, but the locations can't support a server of their own, at least not right now.
|
|
|
|
|
That's a bummer.
Netblue wrote: A better way to do it would be SQL replication
Sure, but then that could open up a new can of worms when trying to manage all those replications and synchronize them, if you needed to. Maybe not, because I don't know what kind of data flow or volume you are dealing with.
"The clue train passed his station without stopping." - John Simmons / outlaw programmer
"Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon
"Not only do you continue to babble nonsense, you can't even correctly remember the nonsense you babbled just minutes ago." - Rob Graham
|
|
|
|
|
Just a second here:
What if the application was being used in the UK, then used in the US or Australia? Conversions do vary...
(though maybe a localised lookup table, and, sure - why not - a little caching or even dare I suggest hardcoding might help perf a little )
cheers,
Chris Maunder
CodeProject.com : C++ MVP
|
|
|
|
|
And then somebody suddently alters some conversions in the database and all clients with the cached data will have an update problem until the next session. To avoid this, we now need a way to let the clients know that the cached data is not up to date. And then....
Honestly, this is exactly what blind obedience to 'good practices' leads to. Of course it's a good idea to make the database work for its money, but this should nonetheless have been avoided. Quick and dirty solutions to correct this lead to still more quick and dirty patches. Recommended practices can not replace thinking.
A while ago he asked me what he should have printed on my business cards. I said 'Wizard'.
I read books which nobody else understand. Then I do something which nobody understands. After that the computer does something which nobody understands. When asked, I say things about the results which nobody understand. But everybody expects miracles from me on a regular basis. Looks to me like the classical definition of a wizard.
|
|
|
|