Nimble:Foreword
From Gneu.org
Contents |
C
Why should you choose C over another language?
Most every language that exists is a super or sub set of C, or it has most definitely been influenced by it, affecting their syntax and even expanded or simplified the built in functions or tests. C has been ported across to just about every machine type, allowing for extremely portable code. C is also known for its simply beautiful structure and refinement ability, which does not impede its ability to perform in any situation. This becomes apparent when you compare code from C with code from other languages. C is also known as a low level language, in that it is not difficult to understand and read for programmers, assuming they know C, while forfeiting some of the power that other, more machine code like, languages have. The closest you can get to machine code is Assembler as far as I know, but please correct me if I am wrong.
C is a procedural programming language, meaning, the language is run as it is written, line by line, left to right. It is very intuitive in this sense, for a new programmer to be able to look at code and understand what it does, as well as how it does it. Writing C code affords you the ability to make what are called libraries. These libraries allow you to save code and reuse it without having to rewrite it. This modularity is intrinsic to C and the languages that are built off of its framework.
What is C used for now a days? I heard that it was extinct
C is still around, it is being used for simple console applications and embedded systems programming. The operating system you are using currently, is at least in part, written in C. C can be used to create anything from a text editor to, what I have been using it for lately, small nitpicky utilities that you would use to speed up production or assist in your homework. I have personally been doing this for years. Any topic that is given a function, especially math and the sciences, is just begging for this. One of the tasks in my biology class was to go through a list of more than two thousand animals nucleotides and pick out the ones that have a certain codon, other people were working on this task all the way up to our final, my small group took some of our application development background and wrote a program that grabbed all sixteen of them. Our application took about twelve seconds to run, and left me smiling in class.
One concept that has to be understood is how C exists in relationship to the development trends. Most applications that the every day user sees are done in what are called windows form applications. Microsoft has built a library that is used to develop all the squares that run around on your desktop. C does not have a windows interface, it runs natively in a console, which is not what people are used to. The idea behind this is that you have the ability to build these graphical user interfaces, GUI’s for short, but you don’t have to. Many applications require a lot of CPU time in order to maximize performance, such as games, which would run choppy and chaotic if they had to use a windows form to display themselves. In short, they are there if you need them, and not if you don’t.
It is stupid; GUI is not gooey. SQL is not Sequel. CPU is not SeaPoo
Programming is simple, being good at it is not.
If it were easy to be a good programmer, there wouldn’t be so many books, articles, websites, wikis, demos, magazines, handouts, dreams, thoughts or opinions on it. It is often a simple calculation of time spent devoted to a subject that will lead one person to gain or lose in comparison over another. A lot of this is evidenced by their skill set and how refined their style is.
Contrary to the above, I would rather work with someone fresh out of school, with very little experience over the older, seasoned, programmer. This is because you can’t teach an old programmer new tricks. They are prone to doing things one way, and having an emotional investment in their choices and style, which may lead to butting heads and arguments, deep into the night. A new programmer is often shown the basics and allowed to build off of them with simple tasks. They are often better commenter’s, which will make or break a coding team.
Style
When I read through my first programming book I didn’t realize it, but as I look back now I realize that every book that I have ever been given, or stolen, has been effecting my programs. This change has been documented time and again, but perhaps most beautifully by a book written by Donald E. Knuth, entitled The Art of Computer Programming. Just as there are multiple ways to say that you are having a good day in your chosen language, programming languages offer many ways to achieve the necessary outcome. This is one of the few things that will make or break a programmer; the acceptance that they are never going to be completely correct, and nor are they always wrong.
Programmers have to have an acceptance of this fact. One person will have a preference to one method over another, called a programmers style. Just as there are different dialects, each incorporating different parts of the language into their dialect, the same is also true in programming. Keep this in mind and your future in programming is going to be easier than you would imagine. I am going to impart my style upon you, and you will impart your style upon me. However existential this view may seem to you, it is true. We all affect everyone else that we show our code to, and their comments affect us.
Another thing to keep in mind is that if there are 8 million programmers in this world, there are 8 million programming styles. Relating back to spoken languages, dialects are often centralized to origins of the people using them, and although the dialects are able to be traced to a single location, they tend to overlap. Southern states in America, tend to have their own twang, New York has its own, as does the west coast. In fact, those of you in the wondrous state of California, you will even find dialects between the different cities, or counties. This is mirrored in programming. you will learn from a series of teachers, all with their own style, you will see that depending upon where the teacher learned their style, and where their teachers taught them theirs, and so on, your understanding will differ from other programmers.
Readability
I assure you that no matter how adamant your teacher may believe he or she is, there is no true way to do any one task with a computer. There are ways to do things that are more appropriate to a task, though. One of the other battles that a programmer has to have with his teacher is learning when concise is necessary and when to be verbose. None of us want to write pages upon pages of code when lines will suffice, but there are situations in which writing a page is much more suitable, because of readability. For a gauge, you can use a zero to ten scale of readability. Zero is concise code, it is very simple, but may be harder to read than Latin. Personally, I like to sit in and around a four. My code is sleek, stylish and comes with adequate comments when I am using cryptic or hard to understand things.
Comments
Since we are on the topic of comments, I would like to stress that commenting is by far the most overlooked partition of this world that has become programming. There are reasons for leaving code devoid of comments, but if you are planning on having the code read again, by you or anyone else for that matter, you should absolutely comment. Taking the time to do so will not only show your code’s intended duties, but also your mind set, Allowing you to come back to the code in two weeks or two years and still know what you are looking at. It also helps when you want to update, or try something new.
I try to explain, in as few words as are necessary, the purpose of my program, function or in many case’s a single line. Nothing is worse than when someone pastes you a chunk of your code that you haven’t seen in years, which you clearly wouldn’t understand any more, except if they ask you a question that a comment would have averted. If you are planning on working with me, or you would like me to look at code of yours, I would suggest that you comment and space your code appropriately, or I won’t even bother to read it. I wouldn’t expect anyone to read my code if it was obfuscated.
Whitespace
One of the things that pass a nubile programmer’s mind is the idea of whitespace having a purpose. Adding appropriate amounts of whitespace may be enough to move your code from a 1 or 2 on the readability scale up to a 4 or 5 is whitespace. You shouldn’t rely on whitespace alone, combining commenting and whitespace is by far the best strategy to good coding style. Tabbing and spacing are not mandatory by any means but they are still under the same category, and a necessity of a programmer who is interested in readability.
Naming Conventions
Naming Conventions are another place where I find that many programmers have dropped the ball. With the exception of quick development cycles and unplanned releases, naming is crucial. Naming variables, functions, structures and even later classes, and namespaces, hold many people back, stylistically speaking. There shouldn’t be any variables with any less than 3 letters, without proper reasoning and justification. There should also be an agreement with the idea that functions and variables are different. Variables are information, and functions manipulate that information. For that reason alone variables are nouns, and functions are verbs. It makes about as much sense to call a function height as it would to say that I just cowed someone. There are many options, keeping these rules in mind, which are still going to influence names of the various parts of your items.
Refinement
I would suggest that if you are tending to do a certain thing with your code that it might be time to reflect upon it. Look at it objectively and compare it to another person’s code. Try to explain to yourself why you code the way you do, and if you are justified in your ways, explain it to another person. You will either be helped and steered another route, or you will steer them.
Closing
I would like to thank you all for coming across this group of articles/wikibook and assure you that I will be doing everything in my power to give you everything you will need to know in order to consider programming as a career and or make the decision to be a programmer. I plan to release one of these in each and every language I know, as soon as I can pull the words together. Above all else, please keep in mind that no one was born a programmer; they all put many years into the process. It is an evolution that is not beyond anyone, but may seem daunting no matter what anyone’s background or future. I have worked with people who started their adventure into the programming realm with no experience with computers and just took to it well, and I have worked along side people who thought they were the cats meow, but weren’t very good programmers. I recently fell across an audio piece from a man named Paul Graham, in which he gets rather verbose describing Great Hackers. It was a motivational piece, to say the least, but it actually answered many questions for me, and I would highly suggest that you look at yourself and ask yourself a few questions before you decide to pick up your pail and light saber; traversing into the jungle of programming is not a paved road that you can simply follow, you have to create your own path, and deciding to follow may be a good choice now, but ego may play a part in your choice to fork or forge, all depends upon what you may see as your future and what you may be urged towards or away from. Above all else, keep your head up and try to continue through this as smoothly as you can. I wish you luck, and I hope that you do well.
