Teoretycznie dany użytkownik mógłby mieć "gdzieś w profilu" zaznaczone jaki typ odpowiedzi go interesuje - dostanie AC czy też zrozumienie programowania czy bycie lepszym programistą.
Póki nie zacząłem pracować jako programista myślałem przede wszystkim o tym pierwszym. O tym, że kod przede wszystkim ma działać i dawać prawidłową odpowiedź. Dzisiaj wiem, że ważniejsze jest to by kod wyglądał jak najczytelniej by inni mogli go czytać i poprawiać w razie czegoś, a działać ma również (jak gdyby był to dodatek). Aktualnie wiem, że piszę kod nie dla komputera, ale dla siebie (bym jutro wiedział co tu jest napisane) i dla innych. Jeżeli teraz myślimy o tym by pytający stał się dobrym programistą (co prawdopodobnie wynika z troski) dobrą podpowiedzią jest wskazanie gdzie szukać, co doczytać, czego się dowiedzieć, jak poprawić czytelność.
Fragment jednej świetnej książki, którą czytam (ważne: książki o tym jak rozwiązywać zadania!):
A Program as an Essay
When students are asked, “What is the most important feature a program should have?”
many answer, “It should run.” By “run,” they mean that the program executes and actually
does something.
Wrong. As with any new endeavor, it is important to get the fundamentals correct right
at the beginning. So RULE 2 is this:
Rule 2: A program is a human-readable essay on problem solving that also
happens to execute on a computer.
A program is an object to be read by another person, just as is any other essay. Although
it is true that a program is written in such a way that a computer can execute it, it is still
a human-readable essay. If your program is written so that it runs, and even runs correctly
(notice we have not discussed “correctly” yet!), but is unreadable, then it is really fairly
worthless.
The question is why? Why should it be that people must read it? Why isn’t running
good enough? Who’s going to read it anyway? Let’s answer the last question first. The person
who is going to read it the most is you! That’s correct, you have to read the programs you
are writing all the time. Every time you put your program away for some period of time
and come back to it, you have to reread what you wrote and understand what you were
thinking. Your program is a record of your thoughts on solving the problem, and you have
to be able to read your program to work with it, update it, add to it, and so on.
Furthermore, once you get out of the academic environment where you write programs
solely for yourself, you will be writing programs with other people as a group. Your mates
have to be able to read what you wrote! Think of the process as developing a newspaper
edition. Everyone has to be able to read each others’ content so that the edition, as a whole,
makes sense. Just writing words on paper isn’t enough—they have to fit together.
Our goal is to write programs that other people can read, as well as be run.
Oraz o samym rozwiązywaniu (strona w cześniej):
It’s All About Problem Solving
If the rules of poetry are what guides writing good poetry, what are the guidelines for writing
good programs? That is, what is it we have to learn to transition from a literal translation to
a good poem?
For programming, it is problem solving. When you write a program, you are creating, in
some detail, how it is that you think a particular problem or some class of problems should
be solved. Thus, the program represents, in a very accessible way, your thoughts on problem
solving. Your thoughts! That means that before you write the program you must have some
thoughts.
It is a common practice, even among veteran programmers, to get a problem and
immediately sit down and start writing a program. Typically that approach results in a mess, and,
for the beginning programmer, it results in an unsolved problem. Figuring out how to solve a
problem requires some initial thought. If you think before you program, you better understand
what the problem requires as well as the best strategies you might use to solve that problem.
Remember the two-level problem? Writing a program as you figure out how to solve a
problem means that you are working at two levels at once: the problem-solving level and
the programming level. That is more difficult than doing things sequentially. You should sit
down and think about the problem and how you want to solve it before you start writing
the program. We will talk more about this later, but the rule is this:
Rule 1: Think before you program!
Myślę, że gdyby pytający skierowywali się ku tym dwóm zasadom, to ich programy byłyby lepsze, szybciej dochodzili by do odpowiedzi i rzadziej pytali o to samo. Tak więc na nie odpowiadający powinni na te dwie zasady kierować. Pełna lista początkowych zasad z książki:
Rules
• RULE 1: Think before you program!
• RULE 2: A program is a human-readable essay on problem solving that also happens
to execute on a computer.
• RULE 3: The best way to improve your programming and problem skills is to practice!
• RULE 4: A foolish consistency is the hobgoblin of little minds.
• RULE 5: Test your code, often and thoroughly!
Książka: Practice computing using Python
- wydanie drugie.