how do you code?

[MikkyThomeon]

Hi

A bit of background about mysely - I started out studying electronics and got introduced to programming by programming microcontrollers in PIC assembler. I was amazed at these little devices and decided to take an additional subject that introduced me to the basics of C programming. At my PC at home (about 9 years back) I found a free copy of VB5 control creation edition and started playing with that and teaching myself the language. Eventually I took some of the MCSD subjects and finally settled into a job programming. I have never been fortunate to have worked with other programmers and developers and have had nobody to learn from other than my research on the internet with the help of a few great people (most of whom live in VBForums!)

I read about OOP and became more intrigued with this the more I heard about it, mainly with the aim to produce standalone reusable objects (which was never really possible in VB6). I am now in the frame of mind where everything I code I try and model it into an object that can be fitted into an object model, but somewhere down the line my mind throught pattern gets distracted by the relationships of things. I am also the type of person who hardly ever uses somebody else's code but try and do it myself 99% of the time.

My latest thoughts about coding are such: Bugger the programming and the object relationships - these are secondary to the flow of the code which is really what makes things work. So now I am using excel to document the flow of things in pseudocode before I get to the coding part. After that I use ArgoUML to produce class diagrams and I map my pseudocode to objects.

My hangups about all the hype talk has led me to never developing great programs because of OOP and me trying to make my VB code as efficient as possible instead of just getting it to work first off.

What I am really keen to know is how you do it and what has really worked for you - and this means that you should be a programmer that can anly be able to write programs of around 20000 lines of VB code or more. What procedure do you use?

Keen for answers!!!
Mike

[penagate]

First, make it work. Then, make it elegant. Then, make it work again. Repeat until boss becomes irate at amount of hours logged against project, then stop at next working point.


Seriously, it sounds like you want to research a few different programming paradigms. Object-oriented, procedural, relational, set-based, and functional languages all have their places—to name but a few. The best design applies the most appropriate paradigm for each component.

Everyone has their own style of development which comes about through time and experience.

[penagate]

Fully object-oriented architectures blow, by the way. Read why.

[Hack]

First, make it work. Then, make it elegant. Then, make it work again. Repeat until boss becomes irate at amount of hours logged against project, then stop at next working point.

This is how I've done it for nearly 30 years.

[MikkyThomeon]

Thanks for the input. (30 years - - -EEEEK dude! Thats more than 3x my worth right now)

I think the one paradigm shift I am going to have to experience is to go back to my old roots of more procedural style programming. I would love to develop person classes that have associated account classes but that slows down my delivery to a crawl.

So maybe first off code everything willy nilly, then later if I need to modify it and build it bigger then convert it to OO. Or as described in the post, only code things selectively that are only 100% likely to be reused. Its quite logical that if its not going to be used then why try and make it reusable!

I think there may be a lot of others out there in my boat...

[Hack]

I think you have a logical, thought out approach.

However, those nasty, evil things more commonly referred to as "deadlines" are ever present thus requiring abandoning what you know would be the right way and adopting the fast way.

[Davadvice]

i don't have time to have any thought of How i would like to do it, i just have to do it because it needs done, yesterday.

i'm with penagate here!

david

[Max Peck]

This is how I've done it for nearly 30 years.

Me too, Hack. I count myself fortunate to have spent 30 years making a living at something I enjoyed doing for free. Not too many people can say same.

-Max

[szlamany]

... these are secondary to the flow of the code which is really what makes things work. So now I am using excel to document the flow of things in pseudocode before I get to the coding part. After that I use ArgoUML to produce class diagrams and I map my pseudocode to objects.

I've also been at this for 30 years...

At any rate - I think what is more important then anything else - and I try so hard to get my programming staff to follow this...

Is how do you debug your code??

I think the only way to develop clean code (and I say that with tongue in cheek) is to code a line or two or even a dozen and then step through it and watch it execute. Then change some values and watch it execute again. And don't leave that logic or that function or that sub until you are sure it's tested.

I've watched people code for hours - then hit run - and try to figure out what's happening and why it didn't work as expected...

As for OO - how your compartmentalize your functions and subs is less important then the fact that you do compartmentalize them. When I code in .Net I follow OO for no good reason other then you are supposed to (and I find it interesting to code in this fashion). When I code in VB6 I use old techniques that I've built on that work well for me.

When I coded in .Net for a pocket-pc app we have I thought only about small and tiny - which meant OO went out the window for the most part. I did create a class to manage the read/write of data to a config XML file. But otherwise almost all other code sat in the single FORM in this app and called sub's and func's in that form.

As for flowcharting - after you have coded for a few decades you have done pretty much everything that can be done with logic - about a zillion times! So your repertoire of techniques is almost at your fingertips. Isn't that sick

[Pasvorto]

I have been in the computer industry for 30 years also... Lot of old vatos here.
I make sure each subroutine has an 'on error...' rountine that lists the error number and description. That way, I can go right to the subrountine in which an error occurs and not spend time debugging code that has no bearing on the problem.

[Hack]

Lot of old vatos here.

I think that is a compliment, so thank you.

I make sure each subroutine has an 'on error...' rountine that lists the error number and description. That way, I can go right to the subrountine in which an error occurs and not spend time debugging code that has no bearing on the problem.

I do the same with an additional step. I write all errors back to an error log table that includes the err.number, err.description, name of person logged on at the time, the sub/function/event in which the error occurred and the date/time the error occured.

That way, when I get a report of an error, I can sit right at my desk and look at the error log table and know who, when, what and where.

[techgnome]

This is how I've done it for nearly 30 years.

Me too, Hack. I count myself fortunate to have spent 30 years making a living at something I enjoyed doing for free. Not too many people can say same.
-Max

I've also been at this for 30 years...

I have been in the computer industry for 30 years also...

You guys are my new heroes.... I've only been at this professionaly for jsut over 15 years.... been attached to a keyboard for a little over 20 years....

At any rate - I think what is more important then anything else - and I try so hard to get my programming staff to follow this...
Is how do you debug your code??
I think the only way to develop clean code (and I say that with tongue in cheek) is to code a line or two or even a dozen and then step through it and watch it execute. Then change some values and watch it execute again. And don't leave that logic or that function or that sub until you are sure it's tested.
I've watched people code for hours - then hit run - and try to figure out what's happening and why it didn't work as expected...
As for OO - how your compartmentalize your functions and subs is less important then the fact that you do compartmentalize them. When I code in .Net I follow OO for no good reason other then you are supposed to (and I find it interesting to code in this fashion). When I code in VB6 I use old techniques that I've built on that work well for me.
When I coded in .Net for a pocket-pc app we have I thought only about small and tiny - which meant OO went out the window for the most part. I did create a class to manage the read/write of data to a config XML file. But otherwise almost all other code sat in the single FORM in this app and called sub's and func's in that form.
As for flowcharting - after you have coded for a few decades you have done pretty much everything that can be done with logic - about a zillion times! So your repertoire of techniques is almost at your fingertips. Isn't that sick

Sometimes it's never that easy. I've worked on required the near full development of way too many components before any of them can be tested.... but...

I make sure each subroutine has an 'on error...' rountine that lists the error number and description. That way, I can go right to the subrountine in which an error occurs and not spend time debugging code that has no bearing on the problem.

this is how I get around that "where the heck did things go wrong".... More often than not though, the problem isn't something caught by an error handler. it's usually in the caclulations themselves.

But if I can, I build in blocks.... get A working before I try to add B.... get that working before C can be started.... drives clients up a wall sometimes, but it's the best way to go.

-tg

[Pasvorto]

the smaller the subroutine, the easier to find exactly where things went amiss.

[Hack]

the smaller the subroutine, the easier to find exactly where things went amiss.

True, by Murphy's Law clearly states that errors don't happen in easy to find places.

[techgnome]

Fortunately they are always guaranteed to be in the last place you look.

That aside.... smaller routines.... great theory..... in practice, things are never that simple.

Rule of thumb.... if someone says "It should be as easy as ......" .... double the estimate and add 15%. And that does not include Design ,testing or anything else.

-tg

[Pasvorto]

Murphy was an optimist

[Shaggy Hiker]

First off, I'd like to dispute the last line of your first paragraph. There are plenty of people who reside here, but to call that living stretches the very definition beyond all recognition.

My philosophy is design first, then code. Designing takes lots of walking around thinking about how I want to interact with the data, how I want to store the data, and whether or not that squirrel would taste good deep fried. The current project I am working on is highly nebulous, so it has taken lots of walking around while trying to figure out how to get very abstract concepts into database tables, and how to create an interface that will make working with these abstract concepts meaningful. Each day I've covered up to six miles just wandering around thinking. Now, after a few weeks of that, I'm so far away I'm not even sure if I can find my way home.

Actually, the most contentious part of this project is arguing about the definitions of words that we all use, but use in many places, and mean different things by. However, after all the wandering around, thinking, diagraming, and arguing, I think I have a viable design, and a concept as to how the interface should look. Now I can start actually creating the interface.

One other thing I have begun to recognize is that I should write EVERYTHING down. Computers, and a fast typing ability, makes this considerably easier, but my notes on the current project are 25 pages long, single spaced. That's with the dead ends removed. Trying to retain all that in my head is pretty much impossible, which is what Szlamany was getting at. Humans, even very smart ones, can only hold a certain number of concepts in their head at any one time. Therefore, procedural programming was created so that we could break a project down into discrete chunks. OO went one better on that, but the reason was the same. Once a program grows above a trivial size, we can't keep the logic of all pieces of it current in our head at the same time. Comments are good, testing is good, and documenting is good.

One other thing I do if I can find the time to do it, is a thorough code review. I have never sat down and gone over a program line by line without finding many improvements, regardless of how well it is working, or how thoroughly tested. If it works, it can still be improved by reviewing it function by function and line by line. Documenting the code is a good excuse to do just that. I'm currently documenting the robot code I am working on, but I keep getting side tracked by improvements and enhancements. Since the code worked, I may never have found these improvements without sitting down to do the documentation. When I couldn't explain why some code was there, it meant there was an opportunity for improvement.

[szlamany]

About 8 years ago I did a consulting gig at Anthem blue/cross - they took code review to a whole new level.

You got your assignment - spent 4 days of each week coding it - and every Friday you and your co-workers would look at each others code. Code review by committee.

It worked well. Everyone on each small team helped push the quality level of code up and the bug count down.

That was in the "development building".

Once code was ready for release you wrote a document describing what you wrote - why you did it - how it worked - what to do if the function aborted, yadda, yadda. Sent all this to the "production building" where their own team of people (who you never met face-to-face) would decide if it was clean enough (through their own review process) to make it into production.

A business like this, insurance carrier (banks and the phone company are at this same level) have a 0 tolerance for bugs. Doesn't mean they don't get them

I remember when this bug hit us here in the northeast...

January 15, 1990 -- AT&T Network Outage. A bug in a new release of the software that controls AT&T's #4ESS long distance switches causes these mammoth computers to crash when they receive a specific message from one of their neighboring machines -- a message that the neighbors send out when they recover from a crash.

One day a switch in New York crashes and reboots, causing its neighboring switches to crash, then their neighbors' neighbors, and so on. Soon, 114 switches are crashing and rebooting every six seconds, leaving an estimated 60 thousand people without long distance service for nine hours. The fix: engineers load the previous software release.

http://www.wired.com/software/coolap...urrentPage=all

[RobDog888]

You have to put some designing and planning or else you will spend much more time coding to rework changes you encountered by not designing a plan. It doesnt have to be elaborate or time consuming but basic flowcharting can help dramatically with minimal time applied.

Other then that its the same as others, code the basics and make it work all within time budgets. Then add extra features or presentation effects. When done if time allows, post at VBF

Coding professionaly for ~15 years (25+ overall )

[Shaggy Hiker]

Coding Professionally: Maybe 1 year.

Coding Unprofessionally: Most of 30 years.

Doing Everything Else Unprofessionally: 40 years and counting.

If you can't age gracefully, age disgracefully!!

[MikkyThomeon]

Hi Guys

Thanks for all the responses. Its got to a point where I want to achieve more by doing less and its amazing what hype can do to avert the efforts of a would be guru developer nowdays.

I was developing an OO game from scratch and was getting lost trying to tie up the compartments with the logic so hence my post.