|
I took a job once, with no knowledge of VB (Visual Studio 6). Hey, I just wanted a well paying part time job to finish my master's degree.
One of the 'best practices' of the company was to always add "On Error Resume Next" at the beginning of each and every function. I asked why, and the reply was that it just works better that way.
The job paid the bills, I graduated, I got a new job, the company went under (not because I left, but I saw the writing on the wall ahead of time - they had too many people and no contracts lined up).
|
|
|
|
|
On Error Resume Next
Is from before the .net era and is a bad programming practice
|
|
|
|
|
I should have left out the try catch
|
|
|
|
|
|
When dealing with a database, sometimes there are bad records.
I meant for these try catches to be this way, as I don't care at this point why there would be problems in the data, all other errors are handled.
|
|
|
|
|
Then catch the DB errors and rethrow the rest.
|
|
|
|
|
|
Heh? so you don't want your user to know to tell the DBA or YOU that something is wrong between the application and the database it uses? Hiding such things is asking for problems down the road. BIG problems.
|
|
|
|
|
It does not use a database.
|
|
|
|
|
You know, you could have avoided a whole lot of discussion just by adding a comment saying that. I too sometimes add error handling code that I know I don't really care about, just to make a point that I did consider the possibility of that error. And, of course, if someone later adds to the code, he may need to reassess if the error can really be ignored - if the (emty) error handling code is already there, then it's much less likely he'll forget to deal with it. 
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
The code was a quick attempt at a just works client. My laziness just so happened to spill over into this thread 
|
|
|
|
|
It's exactly that 'just works' mentality that needlessly causes hours and days of maintenance effort when it comes to figuring out what a buggy function does, or what it takes to adapt it to a new functionality without introducing regressions. If you care about the state of your program in 6, or even 2 months, then you should care about comments and think beyond 'just works'.
Not saying or implying that this is your professional style of coding, but it is all that we see here, so don't be surprised if people react and respond accordingly.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
We don't spend time on bugs, we use Unidex.
|
|
|
|
|
Which nobody here appears to know, and on google turns up blank. Meaning the only reference to your coding is the lazy sample you gave us.
P.S.:
If you didn't find bugs, you didn't test enough.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
modified 16-Jun-14 8:21am.
|
|
|
|
|
|
I do miss the with operator. I have cases where it could save hundreds of characters and make it way easier to read.
Don't listen to the C# purists. 
There are only 10 types of people in the world, those who understand binary and those who don't.
|
|
|
|
|
RyanDev wrote: and make it way easier to read
I would argue the opposite.
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
A lot of people do. I can't understand why, but yes, a lot of people do.
There are only 10 types of people in the world, those who understand binary and those who don't.
|
|
|
|
|
visual basic is easier for people with less skill
|
|
|
|
|
I agree. So if you're intent on hiring people with low skills, VB is a reasonable choice.
Most hiring staff want people with high skills though...
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
Do you know what its like in an agile environment with highly skilled programmers that all think they are the best and try to leave there mark on a program?
Not only do they cost more, they wasted extra hours, and broke the conditions of the client.
Most of the places that want high skills are getting over qualified people for simple tasks in a lot of cases, there is so mush wasted talent that could benefit from a team of code monkey's, these people carry out the thoughts of the skilled programmer.
If skilled programmers came with code monkey's I would hire them
|
|
|
|
|
It all depends on the kind of work at hand:
I've been working with high skilled programmers for 30 years, and my experience is quite the opposite. The applications were all quite large and complex, or had highly innovative and complex functionality, or both.
Of course if the job at hand is more mechanical in nature and doesn't require the coder to really think out of the box, then a skilled programmer won't be happy, and will quit, or not even apply to the job in the first place.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
My family owns a factory warranty center for Panasonic, growing up I was trained on programming microchips.
When I deal with people and they tell me they know computers my first thought is to think they are full of themselves.
|
|
|
|
|
With, when used appropriately, aids clarity just by removing characters – if you have to read past "SomeLongObjectName." at the start of every line you won't actually see the important word. When used badly (so you don't know whether the tokens on the line are part of the with'd object or locals or something else) it makes things worse. I've used with in ActionScript, usually for graphics code which is doing nothing but a bunch of calls to lineTo, moveTo, setBitmapFill etc, and (imo anyway) not having "e.graphics." on every line makes that clearer.
|
|
|
|
|
BobJanova wrote: doing nothing but a bunch of calls to lineTo, moveTo, setBitmapFill etc, and
(imo anyway) not having "e.graphics." on every line makes that clearer
Howsabout writing a function then? Now I'm wondering wether or not an anomymous function would do that...
You'll never get very far if all you do is follow instructions.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
