|
Just joking - I do concede that it's remarkably well structured for a BASIC program. Bonus points for using declarative variable names! 
But don't expect me to have a look and understand what it really does - I'm sure I could do it, but I've never programmed in VB and don't intend to start now 
|
|
|
|
|
It simplifies the use of arrays to be allowed to be controlled more like collections without the overhead.
That is a self contained module of a 4000 line program.
No basic program here.
|
|
|
|
|
Colborne_Greg wrote: All of my code is self documenting enough that maintenance well never happens because it was written clear and concise to begin with.
Okay, here's my challenge: Find the error(s) in your above statement.
|
|
|
|
|
I failed English,
I started programming before I started highschool, its like I think in code, then have to translate to English
|
|
|
|
|
Not to be a smart-a$$, but if you failed English, how can I as a user/buyer/customer/manager of your software be reasonably assured that you understood the requirements well-enough to implement them accurately?
|
|
|
|
|
I've only met one project managers, one client, and two senior developers capable of giving concise requirements.
If a client say "this needs to be for each item", when really they mean "this needs to be shared by all items", then no understanding of English will help. Only an understanding on the clients business will help, that way you can understand what they mean even though it's not what they said.
|
|
|
|
|
As a owner of two companies I don't see your point, and if I was stupid enough not to have someone go over my work before trying to sell an app well it wont make money will it.
Grade 12 math ability in grade 2... English is for communications, it means nothing to the end result, unless English is the only way possible for you to understand something, then I would be worried more about you.
|
|
|
|
|
Colborne_Greg wrote: Here is an example of code, with no documentation, lets see if you can figure out what it does.
The fallacy in that statement is that it presumes that the reader only needs to know what the code does.
However to maintain code one also needs to know 'why' code is doing what it it does. For example, in your code example 'why' is "Nothing" acceptable? Is the caller expecting that as a valid condition or is the caller going to error on that? Or perhaps it is up to the caller to decide that themselves?
Additionally how does that work for a caller who wants to use the code but does not care how it is implemented? Where is the contract for the code defined? How can the caller be sure that even if the implementation changes that the contract will not? How will the maintainer be sure that they can make a modification to that code without breaking that code?
|
|
|
|
|
In generic programming there is no why.
As a programmer of 25 years, we in the field usually did not comment code or even tried to make the code readable, job security...
That is retired code, otherwise I would not allow anyone else to see my work, as the concepts are experimental and solve just about every problem known in computing.
Also if a programmer I hire creates a piece of code that was not well thought out in the first place, and it comes down to that code needing to be maintained that person is gone. Then I go over the code myself and make it generic to last the ages. See I believe that if you can't understand code just by reading it, you need more experience, the readability should just be what gets the job done faster.
|
|
|
|
|
Colborne_Greg wrote: and it comes down to that code needing to be maintained that person is gone. Then I go over the code myself and make it generic to last the ages.
All I can say is that you work in vastly different industries than I do.
Or you don't work with anyone else.
Code doesn't last "ages" because requirements don't. Requirements can change monthly (thankfully they don't change even more often than that.) Individuals work on certain code by themselves for years and then move on leaving someone else to figure it out.
I write code with the goal of allowing someone else to be able to modify it and understand it because I know it will happen.
|
|
|
|
|
How much does the code structure of SQL changes?
Like never, and SQL is my competitor, Unidex which was invented in 2003 to index characters in memory, therefor every single column is indexed, and every record can have all or none of the columns in a table or extras only for that one record, it can also store pictures, songs and video inside a record.
Code does last for ages, the code that doesn't wasn't written correctly.
|
|
|
|
|
Colborne_Greg wrote: How much does the code structure of SQL changes?
The language? Since no one actually uses just SQL and rather they use a vendor specific extension, such as PL/SQL the question is rather moot. And PL/SQL and TSQL changes every couple of years.
But even those don't change that much - but then that is far, far from what the vast majority of programmers do. The write with SQL they don't create the language itself.
Colborne_Greg wrote: Code does last for ages, the code that doesn't wasn't written correctly.
As I already said, and pointed out, no it doesn't. There are applications that will not run on newer systems. There are new applications that will not run on old systems.
I have personally worked on multi-million dollar projects that were delivered ahead of time and which were accepted by the customer and yet was never used at all by the customer.
I have worked on a project that went through tens of millions of dollars and after 7 years the vast bulk of the software (and entire service suite offering) was abandoned. This is despite the fact that it was successfully processing 4 billion dollars in transactions at the end.
I worked on the project that very, very likely allows your current phone to work and I know for a fact that although conceptually the system is the same the details have changed.
|
|
|
|
|
again I state Quote: Code does last for ages, the code that doesn't wasn't written correctly.
Also look into generic programing
Its what programmers should be doing, and when they do the code lasts forever.
Oh look code really does last for a long time
|
|
|
|
|
I think it's time for you to move forward from living in the late Paleolithic in terms of developer tools to the modern era where superb tools like .NET's compiler, Visual Studio, and add-ons like ReSharper, help make coding much more efficient.
It's always going to be a "Tower of Bable" out there, in the real world.
But, if you enjoy living without the wheel, fine.
“I speak in a poem of the ancient food of heroes: humiliation, unhappiness, discord. Those things are given to us to transform, so that we may make from the miserable circumstances of our lives things that are eternal, or aspire to be so.” Jorge Luis Borges
|
|
|
|
|
So you want to learn COBOL?
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Visual Basic .NET have almost all those features
|
|
|
|
|
|
This will not help you if you are comparing two variables ...
|
|
|
|
|
True. But I've found that to be an exception. Most often tests for equality test for a certain (constant) value, whereas tests between actual variables check the order, i. e. they use < or > rather than ==. I've been using Yoda conditionso for more than 20 years, and I can't recall the last time I couldn't apply it. It happens, but it's extremely rare.
|
|
|
|
|
Most of the problems you describe are the reason why coding guidelines and code reviews exist. If you choose not to use coding guidelines, or don't bother to hold reviews to ensure guidelines are followed, many of these problems simply can't be avoided: a language definition can't stop a programmer from calling a variable i rather than, more descriptively, row_index. Only guidelines and reviews can achieve that!
Some specific comments:
3) As pointed out above, variable naming and code documentation cannot be enforced by a language.
4) I disagree: Strong typing helps the compiler (or interpreter, whatever) to decide whether a given statement is ok or maybe a typo. It helps the compiler find many errors of the types you earlier described! The main reason for strongly typed languages is that they improve the automation of error detection in the code. It also helps people understand other people's code, specifically since documentation and sensible variable names cannot be enforced by a language: when you can look up the exact type of a variable, that alone may offer a hint what it is used for. Type information is the only part of code documentation that can be enforced through a language! If documentation is important to you, then you want strong typing!
5) Neither number formats nor definitions of formats are truly universal. You have to accept that anything relating to format either must be defined specifically, or will deliver different reults in different locations.
6) That is a direct conflict with 2: you can't dynamically create new types in a compiled language. That said, your example describes an entirely different situation: that your program can deal with an arbitrary external object. Short answer: impossible. Long answer: Hollywood lies! No you can't interface Alien Computer hardware with a run-off-the-mill lapktop! Not even if you're Jeff Goldblum!
|
|
|
|
|
Something is wrong if you're spending 6 months chasing "==" for "=". With the debuggers/IDEs of today I find chasing them (no, they never go away [someone elses code]) to be fairly efficient.
As for the rest, well, it's the same old programmer-preference thing. No one thing or set of things will satisfy everyone. I believe Abe Lincoln said that. Personally, I really like braces vs. BEGIN/END. Any anyone who feels the need for "// end of some-block" has written a block that is too long; just break it out into smaller chunks/methods/functions.
|
|
|
|
|
The bug was embedded deep within an error recovery routine that got invoked maybe once every 2-3 weeks with the result that the system would crash with little evidence as to why. It had been written by a programmer who had moved on to the next project.
|
|
|
|
|
Sorry. I was harsh. However, a decent language such as my current favorite, C#, almost always catches such things. Eg,
int i = 9;
int j = 10;
if (i = j)
{
DoSomething();
}
... won't compile.
I've been writing code since '81. I cannot find anything to complain about with C#. EVERY other language I've used, not so.
|
|
|
|
|
Sounds good to me.
I have to admit skepticism, though. Even well design systems can be derailed by idiots (or by intelligent noncompliance), or otherwise "gamed" to work against itself. I see it all the time in every human system I encounter.
Figure out how to address that factor in the design, and you've got something.
</soapbox>
I used to call it "Super Happy No-Pants Wonder Day"! It turns out that the police just call it "Tuesday". Go figure...
|
|
|
|
|
I have been in the field for 40 years and have worked fluently in over 12 different languages and their off-shoots including PROLOG.
Hands down, the two best languages I have worked with have always been BASIC and Pascal. However, for ease of use and capability you cannot beat BASIC.
There is no need for a new language since nothing new will be able to do anything better than the existing language stalwarts... At least not until a completely new architecture is available for development.
Steve Naidamast
Black Falcon Software, Inc.
blackfalconsoftware@ix.netcom.com
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
