It basically comes down to basic human nature. We (some of us) tend to be lazy (at least some of the time if not all the time).

We are too lazy...

- to type in long variable names
- to document our code properly
- to explain in writing to someone else what the code does
- to specify input/output requirements of a program function
- to specify which globals are being used and altered

We use acronyms that are short and ambiguous, such as dow, instead of days_of_week.
We continue to write dates such as 06/07/08 which totally useless.
We perpetuate the Y2K bug by taking short cuts and assuming that our code will never see it into the next century (at least I wouldn't, so what me worry).
Life is all "hakuna matata", baby.

 

For the communication thats going to be cool have to get a few girls to help me out with that kidding it will be hard work

The girls are reserved for "Real Brogrammers".
http://www.youtube.com/watch?v=9fVELekxeAo

http://www.quora.com/How-does-a-programmer-become-a-brogrammer

 

Further reading: The Art of Computer Programming, volumes 1, 2, and 3.
By Donald E. Knuth, sometime of Stanford University.
This was intended to be a seven volume series, but only the first three volumes were published. The author may even still be among the living, but he has long since retired from writing and lecturing. Browsing any of his published work will not be a waste of time. The books have been out of print for over thirty years, but will surely be on the shelves of libraries and serious computer installations.

 

I talked to Don at a conference in 2010 and he is still a very interesting person to interact with -- and there were no shortage of folks trying to get him to pump out at least one more of those volumes! During a talk he gave there, he was asked about it and I forget whether he stated or just hinted that Volume IV was in the works. The first part of Volume IV was published last year and the rest is supposedly still in preparation.

 

It basically comes down to basic human nature. We (some of us) tend to be lazy (at least some of the time if not all the time).

We are too lazy...

- to type in long variable names
- to document our code properly
- to explain in writing to someone else what the code does
- to specify input/output requirements of a program function
- to specify which globals are being used and altered

We use acronyms that are short and ambiguous, such as dow, instead of days_of_week.
We continue to write dates such as 06/07/08 which totally useless.
We perpetuate the Y2K bug by taking short cuts and assuming that our code will never see it into the next century (at least I wouldn't, so what me worry).
Life is all "hakuna matata", baby.

I agree and this occurs for many reasons not interested , waste of time belief, pressure , comfort at a certain level of something ,..etc (and this is definitely a limiting factor for some more then others )


as for books like

The Art of Computer Programming, volumes 1, 2, and 3

which are great I have been thru those an know that stuff pretty well.

However this is more the theory not the actual practical way or algorithmic way if possible to figure out how to design a website or structure the tables/columns in a database,...etc

Either way I think I am at a point where no book can help me any more and it is just the exprience I gain on large projects/open source code reading that can maximize my potiential in designing/developing great code.

Thanks for your help but I have found that even the design computer books like antipatterns or code rules of thumb ,...etc I already know so it is the practiceing/doing part that I can only improve on that could maximize my writing great code.

 

I grew up with the late 60's and 70's spaghetti code. To answer your question it WAS simpler to write your own code than to decipher code written by another at that time. However, today's languages and applications are often written in short descriptive modules. i.e. customer info and supplies, etc. These are often stand alone modules that are called by the program when needed. These can be written and read rather easily since they are usually programmed for only one agenda. As for the maximum number of programmers; using the modules technique of today, there is no limit. Just assign each programmer one a part of the program, give them the necessary names of files, etc. For example:One might do Accounts Receivable then another might do Accounts Payable and another inventory and so-on and so-on. Opening different files or even same files at the same time is not a problem today as it was so many years ago.

 

Ok, then I can think of only a couple other areas

1) How to improve your organization skills
2) How to improve your forget full / absent mindness

I know as my spelling,grammer,pronunication/speaking improves this will clear up my note taking issues and alot of my code writting/communication skills.

But From the above 2 problems I am still left with me missing a particular time or miss placing something , taking forever to find what I am looking for. And even in most cases this will also effect the way my code stays written with the same conventions over time.... i.e (Var1 with var2 dyslexic issues )

Curious if anybody knows of away to improve the above 2 problems.

Because if I can clear up the above 2 problems and my spelling,grammer,pronunication/speaking I should be all set. Or at least know that I gave it my best effort/ maximized my potiential to the best of my current abilities offer.

And in theory thats the best anybody can ask for for somebody to maximize his potiential.

I can only think of one way to break a disorganized habit it would hire somebody to constantly watch my actions and comment on where you should place stuff ...etc over time reenforement may break my habits. Of course this is not a practical solution in my current status.

Curious to know if anybody has any alternative methods that he knows of.
Note: drugs or doctors are not ever an option only nature ways.

But I am reaching the point where these problems cann't be solved with anymore books or knowledge just sure hardwork at tough practical situations... I guess start with baby steps

 

I had much the same issues when I was younger, dyslexic, stutter, forgetful. My sub-conscious mind seemed to be so much faster than the conscious expressions of thought so I was out of sync. I needed a way to increase the speed of transmission within my mind. Just like in electronic communications one of the ways to increase speed and reduce errors is to reduce noise. The noise of many thoughts in a jumble in the sub-conscious was my problem. My solution was to start the practice of Hatha yoga (The Western mainly physical version). I learned to slow down my mental process to a very low level at first by clearing the mind then to select a problem and examine it with the clarity and to visualize abstract images of solutions. With the training my sub-conscious mind was just as busy and fast but could now be directed and focused mainly on things of importance instead of random fleeting ideas and the conscious mind could connect at a much deeper level to the sub-conscious.

I know this sounds like a huge pile of dung but it suppressed some really bad habits and I believe improved my ability to be successful at work.

http://en.wikipedia.org/wiki/Hatha_yoga

 

but what extent did it improve the solution to the overall problems you where having?

And I guess it would differ for different folks kind of like stareing at those illusion pictures some people can never stare right to see both sides I guess... to make the analogy.

 

but what extent did it improve the solution to the overall problems you where having?

I know it's helped me for the past 30+ years and if you go to classes in a good neighborhood lots of hot women will be there to help you train.

 

Maybe they would let me be a patient in the communication disorders class alot of hot chicks are there that would probably be willing to help


man I know what is going to come next hard work crap

 

I "maintain" code written over 20 years by more than 20 programmers, many who have moved on. The others run away screaming and crying if I get too close to them!

In my search for enlightenment, I have found several things to be useful:

(1) Variable & function name prefixes:

    ALL CAPS = const
    MixedCase = AsmLabel
    Mixed_Case_With_Underscore = Variable
     G|L|S|R       Global / Local / Static / Register
     S|U|N|T       Signed / Unsigned / uNion / sTructure
     L|S|I|C|B|b   Long / Short / Int / Char / Byte / bit
     A|P           Array / Pointer

     lf|pf	   Local / Public function followed by return value (lfc is a local function returning a char)

(2) Function headers

/*
********************************************************************
**
**  Function:
**
**  Description:
**
**  Parameters:
**
**  Returns:
**
**  Calls:
**
**  Called By:
**
**  Variables:
**
**  Notes:
**
********************************************************************
*/

Note that I'm not very good at maintaining the Calls/Called By/ Variables information. Also, "Called By: Everyone" is valid in my world!

(3) I use FreeMind (found on SourceForge.net) for debugging code; there are other programs that would work as well.

Problem: Description of the problem.
Report A copy of the bug report, however delivered
Analysis My ideas of what could be causing the problem
Examination Verification of the Analysis
Cause What the problem really was
Fix What I did to cure the problem, including file references (RAF.ASM::Label: or File.c::Function() )

(4) Finally, I use a program called "LEO." I use the "4.4 final" rev., because I did not have the patience to download the ancillary programs. There are some bugs associated with the plugins, but I have found it useful enough to keep using it. (4.4 was built in 2006.)

HTH,
--Rich

 

Well in line with what I've been promoting.

Other things I include at the file header:

Name of programmer
Date of start of project
History of revisions - date, name, additions/modifications/corrections/bug fixes etc

 

Well I have to say RiJoRI
Thanks for the example I think that is some of my problem I have to take the
extra time to document and make sure everything is legible/easy to understand
and properly written. ( even though my tendency is to move on to something more fun or cool )

preparation and design are 90% of writting great code
As well as it makes the code much more readable in the long run when you forget it

 

There comes a time when rewriting the code is a good exercise. It will help reorganize your thoughts and allow you to add additional structure in terms of internal documentation (more comments please) and variable naming. In developing a complex program, I may rewrite it two or three times. If I find that I am testing for more and more 'special' conditions, then it is time to reorganize the logical structure. If I find that I need more and more variables - then it is time to reexamine my data structure. If I find operations that are repeated more than twice, I find that it is time for a function or routine.

Also, I find that spending extra time on the data structure makes the program structure easier. As an example of this, I was writing an interpreter and found that by adding one more data value to my data type (a stack variable, containing a pointer to the next command to be executed) vastly simplified my code.

BTW, I still have my copies of all the books mentioned in this thread; I am an old school programmer from the 60's.

 

Some other pieces of advice on making code manageable.
Avoid using constant literals in your code. These should be declared in header files.
Learn to break up complex programs into modules consisting of a header file (.h) and the program file (.c).

The other thing that I have learned is that the use of structures and unions makes the code easier to follow.
I have written many GUI and apps. It makes life a lot easier when you think in terms of objects such as points, lines, rectangles, windows etc.

(I have to admit I have not done any OOP or C++. Most of my apps run on small embedded systems. Hence memory space is very limited.)