I have talked about the extent of writing code and some of the constraints
in that. (i.e typing speed , design time,...etc )

But this thread more focuses on reading code.

I am curious to know a few things about it. (obviously you can read code faster then you can write code but its hard to say weather you can comprehend code fast on average then writing code)

1) If somebody was an expert at a particular language say c/c++ he could easily read or write a simple application pretty quick. However to analysis the reading of code is harder to analysis the extent of what you can write in a day.
Because different people comprehend differently simple put somebody could be an expert at writting code but suck at reading thru large project and understanding them. Simply not being able to read/understand the code you are developing on very well makes it impossible almost to build on the code even if you can write good code.

So my main question is can an expert programmer in a particular language that sucks at reading others code improve on his reading/comprehension abilities of it. Or is there some people just genetically better at figuring out/reading thru code?

To improve reading code obviously practice and a well understanding of the language is a plus. But do different people have different limit... and are these different limit very far off from one another?

The only thing I can think of of improving reading code is to actually start reading , using debuggers to step thru code , and modifying somethings and seeing what happens. After awhile you get more familiar usually.
But is there other ways to improve your reading and comprehending of code... the only other obvious think I can think of is working with others or asking the person who wrote some of it if possible (but even that is a stretch in most case)

Your thoughts

Question 2
What do you guys think is easier ( I have asked a few people and I am getting mixed answers so maybe this below question is opinionated and differs for different people)
Here goes
Provided you are an expert programmer what is harder
writing a simple application or reading/comprehending a simple application that another wrote?

Note this question is very general so feel free to put stipulations on lines of code to write/read or other things if needed to make your choice more precise.


Thanks for any of your thoughts

Seems to me the deterring factor of adding on to a project or writting a new application from another is the fact that you must understand the code being add on to to some extent. Eventually we may hit a point where it gets to complex for a human to do any more but maybe I am wrong this not proven yet.

 

Reading and writing code is a two-way communication issue.
It depends on who wrote the code and who is reading the code.
You can be an expert going both ways but proper effective documentation can go a long way to make your code comprehensible by another programmer.

So it is not just how you write your code but also, more importantly, how you comment and document your code.

For a simple application, it can go either way. A simple application would be just as easy to recreate from scratch as it would be to understand prewritten code.

For me, I would have to say it is easier to create your own code than trying to understand someone else's code. Maybe because you can understand what is in your own head than what is in someone else's head who is not present in front of you.

 

An expert programmer will have acquired or developed tools to help him read code. A very, very old program in use since the early 1960's would read and analyze COBOL code, giving one or more printed reports which the expert would then use. I watched one of my mentors read IBM mainframe object code (in hex notation) about as fast as I can read English, and make patches to the code by overlaying or inserting hex characters. At that time, the idea of disassembler programs was popular, but most of them were designed by wishful thinkers, not code reading experts. So, my conclusion is that reading code teaches you a lot about bad programming techniques, and may suggest a few good programming techniques. The success of reading code for comprehension depends largely on the native ability of the person reading, and his (or her) experience in the particular language, both in source and object form.

As for the second question, my experience says it's easier to write a quick and dirty application than to analyze someone else's QnD code. That's because you know what it is you want to accomplish with the program, and are able to design the program as you go along. You know what the desired results are, and don't have to verify that the other guy's code does what you want. Hence, I'd say it's more difficult to analyze existing code.

 

Ok, how about reaching a point where code gets to complex to maintain or add on. Is there a limit or any definite defining factors for estimating a limit to how complex code can get before a person or team of people cann't build on it any more. And must rewrite.

Another question3 is
maximizing ones ability to comprehend/write code
what do you think are the best ways to get to your max potential in read/comprehending others code and writing great code.

For example
1) aspect of writting good code is to make it maintainable good documentation ,
easy to add on, good naming conventions ,...etc

I am curious with reading/comprehending and writting great code what are the defining qualities or abilities that one should improve on to hit his max potential

in your guys opinion

 

Yes. Research has shown that the effort and length of time to complete a project goes up exponentially with the number of lines of code.
It also increases with the number of programmers put on the project.
Hence there is a limit as to how many programmers you can assign to a project.
By suspicion is that number is somewhere between 3 and 6.

 

how about your thoughts on improving ones abilities to read/comprehend code
and write great code? ( what do you guys think about getting to your max potential and what skills you must exercise/workout sort of speak to get to your max)

And do you believe there is any defining limit on how much code we can build on before an application becomes unmaintainable. In theory one could analysis the amount of time to execute each line of code and get an upper bound on the time it would take to execute so many lines of code per average rate on the cpu or interrupter . Makeing the defining upper bound how long somebody is willing to wait for an application to complete or components to complete in the application.

But then of course with processors improving this would probably never be reach before other factors got involved.
But would be a upper bound relatively loose upper bound though

 

Many of the questions you are asking were posed and answered two or more generations ago in The Psychology of Computer Programming by Gerald M. Weinberg. The book is long since out of print, but worth a read if you can find a copy. There were two editions, either one will do.

 

Great , I will have a look or at least try to find one.

I have to say I am curious of what he thinks.
Since most of these questions cannot be fully/exactly analysis-ed for all cases.
i.e no general theory that gives you the extent or max limit of a person abilities in all cases.

But it would be a good read to see his point of view since alot of things as time goes on and we understand more variable factors...we will beable to get better bounds and know what in practice can be done in terms of a humans abilities to read/write code.

And of course another factor that would help use progress is that not only software programs have to improve but also the computer program languages will improve (i.e have more functionality for else code written ,...etc) and processor improve ,...etc

So with all this improvement coming from everything it would be hard to even say if there is a limit in site.
The only upper rough limit would be the sum of all the upper limits of each particular pieces and that is probably a really big overestimate as well as something we would never reach very soon anyway

 

one other thing

I am good with all most all of the current major programming languages.

But my lack of experience on job settings/large projects makes me poor at my current ability to write great maintainable code what I am interested in is books/things that would help me improve my coding skills (not in the understanding of a particular language but the area of writting/designing great code that customers will love and employees will value )

So other then
1) The Psychology of Computer Programming by Gerald M. Weinberg
2) The Mythical Man-Month: Essays on Software Engineering

Is there any other major books I should look into.
I have read thru software engineering / project management books already and those helped a little bit. But curious other then the fact of good team work / communication skills and reading the above books / practicing is there any other thing I can do ?

I would like to honestly say I have exhausted all possibilities in improving my developing skills for an employer/customer .

So if anybody knows of any other things I can do please post.

I understand my spelling is an issue and semantics/syntax is an issue as well I am going to work on this in the near future

 

Is there any other major books I should look into.

I would have to suggest Extraordinary Popular Delusions and the Madness of Crowds is a history of popular folly by Scottish journalist Charles Mackay, first published in 1841

 

The best way to learn to write good code is to use a language that forces you to structure your ideas into interfaces and implementation sections. You can can do this with C if you follow a few rules about using separate .c and .h files for modules.

Instead of thinking first about the algorithms in detail put a lot of effort into the design of data movement and data requirements of the problem. As you document the interfaces on what the data is for, the actual implementation may change as you see the flow from inputs to outputs. Once you have a good handle on that you can write the implementation code with stubs that at first just return the required data without the complete details as the foundation and build up the complete program from that.

C examples of Modular programming: http://www.eetimes.com/design/embedded/4023876/Modular-Programming-in-C

 

Writing good code is a lot more than just writing code.
There are hundreds of rules and guidelines such as the mundane things like -

- how you indent your code
- how you name your variables
- how you identify data type as part of the variable name
- how you use caps and underscore

just to name a few.

Then there are things such as platform dependencies.

int, short and long data types have been replaced with int8, uint16, uint32, as examples.

 

So my main question is can an expert programmer in a particular language that sucks at reading others code improve on his reading/comprehension abilities of it. Or is there some people just genetically better at figuring out/reading thru code?

To improve reading code obviously practice and a well understanding of the language is a plus. But do different people have different limit... and are these different limit very far off from one another?

Are there some people that are just genetically predisposed to have better balance, or can anyone learn to be a tightrope walker? If there are differences, are they small, or are people very far off from one another?

Pick whatever skill you want - catching footballs, playing a piano, working crossword puzzles. The answer will, for the most part, be the same.

Reading code is, in general, a lot more difficult because for it to be of much use, you have to be able to determine WHY something is being done instead of just WHAT is being done.

For example, consider the following C function:

unsigned int bob(unsigned int n)
{
return n ^ (n << 1);
}

Seeing WHAT it does is pretty trvial, but WHY is it doing it?

or:

unsigned long foobar(unsigned int n)
{
unsigned long a, b, c;

a = b = c = 1;
if (n < 2)
n = 0;
else
n = n-1;
while (n--)
{
a = b + c;
c = b;
b = a;
}
return a;
}

If you were tasked with "reading" this code, what would your conclusion be?

I'm willing to bet that if I just change the name of the function to something appropriate, even if it is still pretty cryptic, most people could say what the purpose of the two functions are almost immediately. Add just a couple of comments, and they both become very easy to understand, including the subtleties in their behavior that can be important when they are actually used.

The point is that you simply can't talk about "reading code". It makes a world of difference is the code is written so as to make it readily readable.

 

Agreed. I have seen the days when variables were limited to 6 characters.
Fortran programmers had this notoriety for writing code that was totally unreadable, such as in your example, with variable names such as K2, M5, R123 and labels such as L456.

There is no excuse now for not using something such as day_of_week, ClearScreen.

 

You can tell FORTRAN programmers from the variable names they use. In FORTRAN the letters I thru N are by default of type INTEGER and others are type REAL. So for loops even today you see people use i,j,k in C language loops as an artifact of FORTRAN usage patterns by the authors of older programming books for students.

 

I have to say my problems can be narrowed down interms of writing great code. In to these Problem areas

1) I always tend to mix up name conventions or have a hard time coming up with ways to name class , structures , modules , variables ,..etc

Reason Why
This is partly because I am not an organized person and tend to be a little absent minded (I know to some extent this is always going to be true but improving it to the best of my ability will improve my code in staying the same format or conventions. (i.e not name a var1 and the making Var2 ,..etc)

2) english spelling and grammer is also a problem
so my documentation or communication of my documented code suffers and makes it hard for other people to understand the doc thus making it on big projects hard to understand my code. Making it not maintainable.

Reason Why I never really cared to much for english it seemed borning
And I may have a learning disablity to some extent with grammer but
To some extent I maybe able to fully over come this with alot of practice
only time will tell what the fundmental reason why I am bad right now with it. (currently there is no defining factors in learning to be good at it with enough practice but signs could point to the fact my spelling/grammer is bad because my prounication is bad )

3) I can think of so many ways to do something that in the end it is hard for me to design or find a good design to use to develop the code. I.E something general enough to make the design scaleable/customizable but not to general that it makes it to overly complicated and to difficult to implement the end results.

Reason Why Don't currently know maybe this only comes with experience
and time. But I would think some people are just more better at designing / picking the right design (just look at the artisits or graphical designer for example some of it can be learn to a respectable level but others is pure talent )

4) A quick way to come up with naming conventions or names for variables structures ,...etc

If anybody has some pointers in improving any of the 4 above problem areas I have with writing great code please let me know asap.

As for reading code

The point is that you simply can't talk about "reading code". It makes a world of difference is the code is written so as to make it readily readable.

Totally agree with you on this one that is why I have been say reading/comprehending the code

For reading the only real thing I can think about getting bet at it is trying to read the hardest code or sloppiest code. And getting more knowledge about the language itself as well as using tools to aid like debuggers ,static analysisers ..etc
But in theory reading code seems to come with time more then anything else, that and maybe an aid persons help from time to time.
So reading I have to say is more experience then it is knowledge to some extent.

Like the fib code by the way
you provided your point very well with those examples
Simply restructuring and a few comments would make it almost instantenous to figure out



Though I have to say it is my communication skills spelling/writing/grammer/speaking/prounication and organization/forgetfulness that are my main problems that hinder me in most areas above. These are trick to break the bad habits it probably as trick in it own way as quiting smoking for some people

 

If it's that hard then maybe you should do something else unless you love it and are prepared to put in the time and effort to make yourself organized ,disciplined and able to handle the complete task. You know what has to be done, so do it.

It's not a put down just an observation.

 

well, thanks for the comment but I was looking for any other things anybody could think of to add / aid me in improving
these issues to the fullest extent.

If there is nothing but what I said that could help then I must simple struggle/work as hard as I can to improve these things as best I can.

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

 

You can tell FORTRAN programmers from the variable names they use. In FORTRAN the letters I thru N are by default of type INTEGER and others are type REAL. So for loops even today you see people use i,j,k in C language loops as an artifact of FORTRAN usage patterns by the authors of older programming books for students.

I think it is more complicated than that. Ask yourself why ForTran has those defaults? It is because those are the letters of the alphabet that are typically used for integers in algebra and other fields of mathematics. Likewise, letters at the end of the alphabet are typically used for real variables and letters at the beginning are typically used for parameters and constants. Those are conventions that long predate ForTran, so if you could somehow blot out the existence of ForTran and started from scratch, it would not be surprising to see very similar, if not the same, conventions adopted all over again.

 

I definitely can't help much with the english skills. I am very fortunate that I am a native english speaker (if you can call 'american' english) at a time when english is the dominant language in most of the areas I am involved in. I know from my efforts to learn a couple of other languages that doing so would only come, if ever, with great effort and time and frustration. Rest assured, your english if far, far better than my skills at any other language you might also speak.

In order to gain a better ability to comprehend code written by someone else, particularly if the commenting is poor, you have to develop the ability to recognize the common tricks that are used to do different things. That, in turn, comes from writing lots of different kinds of code and trying to write code to solve the same problem lots of different ways. You also want to understand as many of the different why's for certain operators as you can. For instance, adding 1 to a value may be for the purpose of incrementing it, or it could be for the purpose of setting the lsb, or for other purposes. Similarly, XORing two values could be for the purpose of selectively inverting something or for checking to see if two values are the same or simply to implement some logic that calls for an XOR.

With a rich set of programming tricks under your belt, you can filter the code you are reading through a whole bunch of different possibilities and pursue the ones that seem to make the most sense.