|
You are seriously off my Xmas list. 
- I would love to change the world, but they won’t give me the source code.
|
|
|
|
|
|
The problem is that VB is a "lazy" language - which makes it easy to learn, and even easier to write bad code in.
And people who start off with VB tend to think the same way: that the way VB works is wonderful, and all other languages restrict them too much by stupidly insisting on the coder spelling out what he wants to do instead of lettign teh compiler have a guess.
So you end up with code that the compiler has guessed, got it wrong, so more code has been wedged in to force the code to work (ish) without the coder knowing exactly why it didn't work in the first place!
And as if that wasn't enough reason, any language which has "On Error Resume Next" is straight from the pits of hell and should be returned post haste! 
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952)
Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
|
|
|
|
|
|
OriginalGriff wrote: The problem is that VB is a "lazy" language
It's a language for airheads.
Regards,
Rob Philpott.
|
|
|
|
|
As a self taught coder with 17+ year’s professional experience, I take objection to your assessment. The industry's obsession with denouncing self teaching and the entire BASIC family of languages really irritates me. Although I can understand how they tend to be linked together. It's no accident self taught coders tend to sprout from BASIC, that's what the language was designed to do. I cut my teeth on GW-BASIC back in the 80s.
In all fairness I can see how self taught coders tend to have a higher percentage of bad habits. However in my observation during countless coder interviews & hires I've found recent college grads are to be voided, unless the project can withstand a productivity drag. Even grads at the top of their class require significant coaching. I find it sad that US colleges seem to be unable to produce coders that can step into a corporate environment and get the job done.
All that said, during those same interviews I realized something else. Self taught coders tend to have raw talent and a wonderful drive to learn. College tends to instill a broad (sometimes even deep) skill base. The best among us tend to have tons of talent, drive, and education.
And for the record… current versions of VB ARE THE SAME AS C# with slightly different syntax. You cannot make an assessment to one without it also applying to the other. IMHO this has caused VB to lose some of its self-teaching ability.
- great coders make code look easy
- When humans are doing things computers could be doing instead, the computers get together late at night and laugh at us. - ¿Neal Ford?
|
|
|
|
|
Repeating code is the worst! It's terrible to maintain a code that is repeated everywhere! Also 'misleading variable names' is really bad..
|
|
|
|
|
Languages, paradigms, frameworks: they're churned out like gas from undercooked beans.
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "As far as we know, our computer has never had an undetected error." - Weisert | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
'All of the above' really isn't necessary. Some of the problems can be corrected easily with modern IDE reformatting and refactoring tools.
That leaves:- Inadequate / incorrect comments
- Mystery side-effects
- Magic numbers
- Swallowing errors
- Not checking input parameters, return values, null testing
Each of these problem areas can arise in code that is otherwise elegant. The problems themselves tend to be inter-related - you get mystery side-effects when you swallow errors, errors that arise from magic numbers (like array sizes) that aren't correct. They aren't amenable to simple fixes, in that each problem needs to be examined individually and an appropriate correction made.
My approach to this sort of thing has been to reformat and refactor until the code is in readable form, and then start defeating the remaining problems in detail.
Software Zen: delete this;
|
|
|
|
|
That was my take also, but you beat me to it!
As I grow older I've found that pleasing everyone is impossible but pissing everyone off is a piece of cake.
|
|
|
|
|
Beat me to it - those were my thoughts as well.
Any decent IDE can easily deal with comments, formatting, etc. It's the other problems that are more important, especially not checking parameters. My last major project had huge issues with people not checking return values or performing even simple testing.
|
|
|
|
|
...is forcing programmers to maintain old or foreign code. Should be punishable by doubled salary.
regards,
Kate
|
|
|
|
|
Looks like you want to punish managers, forcing programmers to maintain old or foreign code, by doubled salary.
|
|
|
|
|
Is it really punishment though? I choose to see it as a fair compensation. Foreign code maintenance (scavenging really) should probably also include one more week of vacation to calm the nerves. I'm glad, that I'm usually on the opposite side doing adoption of cutting edge technologies. But once in a while... 
|
|
|
|
|
Agreed - I was interviewing with one company who was looking for MFC developers. When they ask for something well past its sell-by date like MFC, I always give them a highly inflated number.
It amazes me how many companies want people to work on old legacy crap without a premium. Then they wonder why there's a 'shortage of engineers'.
|
|
|
|
|
While I imagine there are teams that have implemented agile well, in my experience witnessing and having to work with the resulting code, agile/refactoring is essentially the worst because it inherently incorporates all of these problems and represents, in my opinion, the worst of "programming habits."
Marc
|
|
|
|
|
My problem with Agile has always been that there's no plan - just implement whatever the customer wants this week. You're always chasing a moving target. Don't worry about future requirements, just make them happy today. If the product is of any size, the end result is a hacked-together, incoherent mess.
The products I've worked on for the last 15 years or so are multi-year efforts by a team of five to twelve people. If we didn't have a fairly good outline of what we were going to implement, we'd never have finished anything. We've become good enough at it that the 'process' is second nature. Based on requirements, we outline component behaviors and specify interfaces in detail. Ironically, we refactor fairly often as requirements change, especially during product maintenance. We even do 'scrum' to a certain extent, since we build and test almost continuously.
I've been in this trade for over 30 years. Every time I turn around there's a magic bullet being touted to management that will turn software development into a nice box with a crank on the side. Turn the crank, and out comes beautiful, money-making product. Regardless of how many times we tell them, the box continues to produce sh*t.
Software Zen: delete this;
|
|
|
|
|
Gary R. Wheeler wrote: My problem with Agile has always been that there's no plan - just implement whatever the customer wants this week. You're always chasing a moving target. Don't worry about future requirements, just make them happy today. If the product is of any size, the end result is a hacked-together, incoherent mess.
And that is precisely what I've witnessed. Thank you for stating it so concisely!
Marc
|
|
|
|
|
All part of the friendly service, Marc  .
Software Zen: delete this;
|
|
|
|
|
I've always seen agile programming as the-tail-wagging-the-dog.
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "As far as we know, our computer has never had an undetected error." - Weisert | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
Gary R. Wheeler wrote: My problem with Agile has always been that there's no plan - just implement whatever the customer wants this week.
That's not agile - that's chaos.
The agile shop where I work requires specs, sign-off and code reviews. Changes to requirements cause new work items to be generated for a future sprint.
/ravi
|
|
|
|
|
Perhaps I should have phrased that as "My problem with most Agile shops' process". I've read too many anecdotal accounts from folks that describe a very chaotic development environment. There's no buy-in from the marketing crowd into the process. They treat it as 'oh, that's how engineering wants to be told what to do' and leave it at that.
Software Zen: delete this;
|
|
|
|
|
Gary R. Wheeler wrote: There's no buy-in from the marketing crowd into the process.
Yes, that's a common problem. Management has to understand that the organization as a whole (and not just the engineering department) needs to be agile.
/ravi
|
|
|
|
|
Ravi Bhavnani wrote: Management has to understand that the organization as a whole (and not just the engineering department) needs to be agile.
- Management with understanding? Oh yes, head to the science fiction shelf at the end of the corridor, please
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Maybe I've been luckier than most, but the companies (exclusively early-stage) I've worked at since 2000 have had pretty good management in place.
/ravi
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
