How to become good programmer?

[Transistor]

I find myself interesting in programming especially android programming can you share ideas that will help me to become good in programming and it will be good if you will share some links on android programming tutorials.Thank you in advance.

 

[phinds]

I can't really tell you how to become a good programmer but I can tell you for sure, from lots of direct experience, there ARE very good programmers and very bad programmers and the difference in their effectiveness is not 10% or 40% or 90%, it is multiples. My rule of thumb is a factor of 6 to 10 between the worst and the best. Unfortunately, the PAY difference between the worst and the best is rarely more than maybe 50% when it should be a lot more.

SO ... I'm glad to hear you want to become one of the good ones.

The one thing I've noticed most is that the best programmers tend to have a natural talent for and a love of both math and logic.

 

[SteamKing]

Programming is part skill, and like all skills, it needs to be practiced constantly so that you can become good at programming. Write as many programs as you can, but start small and experiment. Later on, when you have acquired some experience, you will find it easier to write larger, more complex programs having mastered smaller apps.

 

[Borg]

Practice, practice, practice and understand that the learning never ends. There's always a new way of doing things.

In my experience, the best developers are conscientious about their work and the worst will just do the minimum required to complete a task. For example, I know many programmers who will be given a bug to fix and will look to see how the bug (and its repair) affects other parts of the system. I've seen other programmers who will 'fix' something and break everything except the thing that they fixed because they didn't look deep enough at the problem.

I haven't looked at Android programming in a while but here's some links. You will have to have a working knowledge in Java though.

Android - Getting started

Android Development - Tutorial

And, don't follow the advice in my signature. :tongue2:

 

[TheDemx27]

One thing I would recommend doing is to comment on a lot of your code. I hate it when someone just posts a bunch of code where you have to figure out for yourself what section does what and the variable names aren't very specific.

 

[berkeman]

I find myself interesting in programming especially android programming can you share ideas that will help me to become good in programming and it will be good if you will share some links on android programming tutorials.Thank you in advance.

One very important skill to gain is to get comfortable and practiced using a "Source Control" system. We've use several over the years here at my work; we currently are using Perforce.

Source control is used to help you track the changes you make in your software (to fix bugs or to add features). It backs up various versions of your code (and the associated include files and library files and make files, etc.), which is a huge help in keeping track of what-all you have done in your code development.

You should also gain some experience with bug tracking systems/software. We used to use Remedy here, but recently switched to JIRA.

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

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

Finally, it's good to learn about the various important subjects in software engineering -- how compilers work, how to use data structures most effectively, how to optimize code, how to organize and document your code most effectively, etc.

Have fun!

 

[Daverz]

One very important skill to gain is to get comfortable and practiced using a "Source Control" system.

And there's GitHub, which is one of the most popular hosting site for free for open source projects.

Bitbucket is from the same company as Jira, and provides free git or mercurial repos and issue tracking. Unlike GitHub, they allow commercial projects to use the service for free for up to 5 users.

 

[Edgardo]

You may find the course Programming Mobile Applications for Android Handheld Systems on Coursera interesting. It starts on Sept 26th 2014.

 

[FactChecker]

1)

One thing I would recommend doing is to comment on a lot of your code. I hate it when someone just posts a bunch of code where you have to figure out for yourself what section does what and the variable names aren't very specific.

I second this. When anyone talks about "self documenting code", poke him in the eye.

2) Learn to make comments that are formatted for a documentation tool like Doxygen.
3) Don't get too cute with your code. Keep it simple.
4) As recommended by others, learn and use a source code configuration management tool. I use Git even when no one else is involved.

 

[rcgldr]

1) I second this. When anyone talks about "self documenting code", poke him in the eye.

So you don't like Cobol?

Since you mentioned android programming, I assume you mean applications programming for some type of android device, as opposed to modifying the android operatins system itself or creating the equivalent of a device driver for the android operating system. So you've already chosen a specific area of programming. Previous posts already included links for android programming so have a look at those.

For a learning process, start with simple android apps, then go on to more complicated ones.

Once you have a job, there will normally be some standards for codiing conventions, source code control, debugging / verification testing, ... , so you will be following those standards, even if they aren't the best. Each project / job usually involves some form of specialization, so your experience in specific fields of programming (and math / science) will evolve as you change projects and or jobs.

 

[D H]

1) I second this. When anyone talks about "self documenting code", poke him in the eye.

And when someone says to use a tool such as GhostDoc to automatically generate that "self documenting code", poke him in both eyes.

 

[Borg]

I guess that I'll add my biggest dislikes.

• That will never happen.
• That will look good on my resume.

First one by customers who later insist that they should have been told about it when their previous decision comes back to bite them.

Second one by developers who overkill a design just so that they can learn a new language or API.

 

[harborsparrow]

Write some programs in any language. Keep coding. Don't name variables things like 'x'--give them descriptive names. Practice, practice, practice. And you'll become good by doing. No amount of studying without also a lot of practice will get you where you want to be.

 

[chiro]

Learn to keep two things in your head as much as you can - state space and flow control.

State space comprises of all the data, its structures, and variables and flow control looks at the execution of
code and how it relates to the values and/or changes in state space.

Practice will help you go from keeping a few things in your head to being able to track entire platforms,
modules, and applications in your head well enough to debug them, modify them, and make use of them as efficiently as possible. The more you code, the easier it will be to keep track of more complex programs and their associated repositories.

The easiest way to do the above is through experience - namely debugging. Debugging will always help in this regard. The other way is through learning how to organize code and data structures and to find a way of mapping these internally (ie in your head) so that you can make sense of the relationships intuitively as you gain more experience, practice, and skills.

 

[preceptor1919]

1) I second this. When anyone talks about "self documenting code", poke him in the eye.

2) Learn to make comments that are formatted for a documentation tool like Doxygen.
3) Don't get too cute with your code. Keep it simple.
4) As recommended by others, learn and use a source code configuration management tool. I use Git even when no one else is involved.

About commenting, how should we know which to comment. Should we put comments on every line of code?

Also, when writing pseudocodes, how should we determine if the pseudocode is understandable by everybody. I got deducted point from our lab because "someone who doesn't know programming" will not understand your code.

 

[FactChecker]

About commenting, how should we know which to comment. Should we put comments on every line of code?

The minimum is to document the purpose, inputs. and outputs of procedures, any section of code within there that has a single purpose, and any parts that are unusually obscure. Beyond that, the programming standards may require more. I add a lot more if I plan to hand off the code to another programmer who is not very experienced with the programming language or the methods being used. References to documents and web-sites that explain algorithms is very helpful and it puts the burden of explanations on the referenced documents. They are usually much clearer than I could be.

Also, when writing pseudocodes, how should we determine if the pseudocode is understandable by everybody. I got deducted point from our lab because "someone who doesn't know programming" will not understand your code.

I think that rephrasing the code into a natural language does not hurt. Just parroting the code is annoying to the reader. I don't have much experience with pseudocode other than the comments that I just described.

 

[Borg]

The minimum is to document the purpose, inputs. and outputs of procedures, any section of code within there that has a single purpose, and any parts that are unusually obscure. Beyond that, the programming standards may require more. I add a lot more if I plan to hand off the code to another programmer who is not very experienced with the programming language or the methods being used. References to documents and web-sites that explain algorithms is very helpful and it puts the burden of explanations on the referenced documents. They are usually much clearer than I could be.

I also will add comments where the code is more complex w.r.t. the requirements that apply to it. In very complex cases, I will list the various scenarios that may occur. I also occasionally reference bug report IDs from the bug reporting systems that we use along with the date and my initials if I think that it would be helpful. On larger projects, one tends to work in the same sections of code such that you may come back to a method that you wrote months or even years earlier. I can't count the number of times that I have saved myself hours of analyzing because of the comments that I put into the code.

Also, when writing pseudocodes, how should we determine if the pseudocode is understandable by everybody. I got deducted point from our lab because "someone who doesn't know programming" will not understand your code.

I think that "someone who doesn't know programming" should learn how to program before trying to understand the code of others.

 

[FactChecker]

I can't count the number of times that I have saved myself hours of analyzing because of the comments that I put into the code.

Amen to that. I have actually spent hours looking at someone's code, trying to understand it, wishing there were more comments. Then I realized that it was my code from years ago.

 

[sourlemon]

Guess I have to poke my eye because I don't comment my code. I only do it when I got "smart" or "dumb" with my code and there is a really good reason for it. I comment on that part so others will know why I did it that way. In general, I try to write descriptive names and lots of test. I use tests as my documentation.

@preceptor1919 You should ask your teacher & TA about the comments. They are the one that grade your work, and they know what they want. In real life, I say, do whatever it is that makes your future self thank you when you have to fix your code.

 

[FactChecker]

I don't comment my code. I only do it when I got "smart" or "dumb" with my code and there is a really good reason for it.

Someone looking through hundreds, maybe hundreds of thousands, of files of code would have to read through each one to find out what it is doing. Each line of code would have to be studied. That would be like a library of books with all the covers torn off and the table of contents removed. When you are writing the code and have it all figured out, it only takes a couple of minutes to put some comments in. Unless you think that your two minutes are worth more than an hour of another person's time, you should put comments in. I often have to look into massive amounts of code that other people have written and I can say that I appreciate good comments. And I am not exaggerating about the hundreds of thousands of code files.

 

[sourlemon]

If you want to add a feature or fix a bug and you have to read the whole system, most likely the system could have been designed better. For example, if you are designing Yahoo, the path to post news and to send an email should be different. Therefore, when you have a bug when sending an email, you shouldn't need to look into a code that post news.

Unless you think that your two minutes are worth more than an hour of another person's time, you should put comments in.

I don't spend 2 minutes putting comments in. Instead, I spend hours writing tests so when I know my code works as expected. It makes it easier for me to debug in the future as well. When I suspect a piece of code doesn't work, all I need to do is change the test, or create a new one. Because I have test example, I will know how to set up the data. Comments can get outdated. With a good test, when the code doesn't match the test expectation, then the test will fail. Comments do not alert you when it gets outdated.

I've worked in big systems before. I've seen my fair share of thousand lines method. I make the argument that if that person had written good test for it, then they wouldn't have written method that big because it would have been really hard to test. If I come across that situation and I have time to refactor and add test, I will. If I am in a rush and the code is really hard to understand, I will add comment or rename some variables to make it more readable.

 

[Borg]

Writing tests is admirable but what if the requirements change and you need to make changes to the section of code that affects your test? Your test will be out of date and you won't have anything telling you how the code was supposed to work.

As far as methods that are a thousand lines long, the people who write things like that usually don't know what they're doing. When I find junk like that, without comments, I just want to scream.

 

[sourlemon]

When you update your code and don't update your test, your test should fail. In that case, you will know that your test is out of date, and you should update your test. This is assuming you run your test after you change your code and hopefully before deployment.

 

[FactChecker]

When you update your code and don't update your test, your test should fail.

That implies that all code should be accompanied by a full-coverage test set. Although that is ideal for safety critical software, it would be unreasonable expensive for most software. And even for safety critical software, tests are not a substitute for clear, well commented code. In addition, a lot of code requires very expensive test facilities to run the tests.

 

[D H]

I beg to differ. Tests are more important than comments.

A somewhat new (ten years old or so) software development paradigm is test driven development. You write the tests of a chunk of software before you write the first line of code. The tests dictate what the software needs to do; the tests are the specification. As code is developed, more and more of the tests pass. Both the tests and the code needs to be changed upon receiving, for example, a new request from the client. The test should always reflect the code. The entire test suite is run every night during a nightly build. Some go even further and advocate continuous integration: The entire test suite (or some manageable portion thereof if the nightly build takes too long) is run every time a change is made to the master branch of the repository.

Because the tests themselves are code, it's easy to determine when the code and test are out of sync. The tests don't pass. How can you tell if the comments are out of date? You can't.

I'm not saying that comments are bad. (Some people do!) It is very easy to go overboard with comments. Consider the following python function:

def nr (x) :
    # Divide x by 2.
    a = x / 2

    # Loop.
    while abs( a*a - x) >= x*1e-15 :
        # Compute average.
        a = (a + x/a) / 2

    # Return result.
    return a

There are a number of problems with the above code. It blows up when called with 0. It loops forever with a negative input, or with a positive integer. The names are terrible, and the comments are even worse. They have negative value. Given a better function name, only one comment is needed, one that says the function is computing the square root of the input argument using Newton-Raphson.

 

[FactChecker]

I

def nr (x) :
    # Divide x by 2.
    a = x / 2

    # Loop.
    while abs( a*a - x) >= x*1e-15 :
        # Compute average.
        a = (a + x/a) / 2

    # Return result.
    return a

Given a better function name, only one comment is needed, one that says the function is computing the square root of the input argument using Newton-Raphson.

This example is a good one, even if it is very simple. You should identify the termination tolerance x*1e-15. You should test for a negative input and probably stay some amount away from 0. That amount should be identified in a variable and a comment should explain it. You might want to include an error return value and comment on the meaning of the error codes. You should identify the role of variables like 'a', which is not universally understood as the answer of the Newton-Raphson algorithm.

Most algorithms are much more complicated than your example. If you refer to a standard reference for an algorithm, you should explain any changes that you made for your application. There will almost certainly be changes. The reference, without indicating your changes would be very misleading and people will be "correcting" your code to match the reference.

In a complicated algorithm where you may be the only person who understands it, those things are important. What if your algorithm is one that can not be looked up in millions of books? Wouldn't you want to at least reference the documentation of your algorithm? Sections of the code should be referenced to sections of a document somewhere, if not documented in the code. I often like to include comments that are the MATLAB implementation lines of my algorithm. I put the comment of the MATLAB line right above the section of code which performs that calculation in my target language (usually C, C++, Perl, or Java).

 

[Medicol]

I beg to differ. Tests are more important than comments.

A somewhat new (ten years old or so) software development paradigm is test driven development. You write the tests of a chunk of software before you write the first line of code. The tests dictate what the software needs to do; the tests are the specification. As code is developed, more and more of the tests pass. Both the tests and the code needs to be changed upon receiving, for example, a new request from the client. The test should always reflect the code. The entire test suite is run every night during a nightly build. Some go even further and advocate continuous integration: The entire test suite (or some manageable portion thereof if the nightly build takes too long) is run every time a change is made to the master branch of the repository.

That's what TDD is for, but your company following the methodology seems too formal :D. For instance, every time the company has to get a new hire, it will take time for training the guy to catch up with the current requirements in a TDD manner, which may slow down the business performance; what should be tested is also an issue; views about TDD tests and code factoring by experienced and non-experienced coders are distinct, etc. You may have a good code review session in your development stage to detect potential bugs, but this in turn also negates what the previous developers have done in the code using TDD approach.

Because the tests themselves are code, it's easy to determine when the code and test are out of sync. The tests don't pass. How can you tell if the comments are out of date? You can't.

Even after you have factored the code for later review purpose, it is still necessary to include some comments of what the part of code under consideration is doing. It is basic though, I prefer to see short comments in all of complex and long loops and they should be informative and make sense. Sometimes we need to also generate them into a file for reference purpose (documentation).

def nr (x) :
    # Divide x by 2.
    a = x / 2

    # Loop.
    while abs( a*a - x) >= x*1e-15 :
        # Compute average.
        a = (a + x/a) / 2

    # Return result.
    return a

There are a number of problems with the above code. It blows up when called with 0. It loops forever with a negative input, or with a positive integer. The names are terrible, and the comments are even worse. They have negative value. Given a better function name, only one comment is needed, one that says the function is computing the square root of the input argument using Newton-Raphson.

Yes, I totally agree. No comment is needed for trivial operations and comments are most favored in part of complex business code.

 

[rcgldr]

Getting back to a more generic response to the orginal question, depending on the type of programming, an important factor is being able to understand and/or design what could be complicated algorithms, and how to convert those algorithms into the code of the programming language you are using.

In the case of android applications, most of what you'll be learning is how to interface with the android device and the android operating system for that device, as opposed to having to deal with complicated algorithms.