Programs

Three rules of good programming. Programming and Automation Rules The Ninth Rule of the Programmer

While learning to program, there are some rules to follow that will make your job easier. These rules are followed by programmers all over the world using all programming languages:

comments - you should get into the habit of adding comments to the code. Even the lines that seem clear in this moment, may become incomprehensible if you return to them in a month;

variable names - use variable names that reflect their purpose. They complement the comments and help you understand the code when you return to it later;

function names – all of the above applies to function names as well. They should describe the actions they perform;

the shorter the better – in Flash there is no limit on the length of a function. However, if you write a function that is 100 lines long, it will be difficult for you to edit it later. It's better to break the function into tasks and put each task in a separate function;

include reusable functions in your code - When programming, don't forget to think about how you can apply this or that function to a similar or analogous task in another part of your program. Let's say you need a function that adds one point to a player's score. Try to use a parameter in it that allows you to add to the score not only one, but also any other number of points;

try not to hardcode - hard coding means including specific numbers in your code. Let's say you use the value 550 to describe the right side of the client field in your code, it will be hard-coded into the program. If you decide to expand the client area to 600 pixels, you will have to change every use of the 550 value in your code. It is better to set a variable at the very beginning called screenRightSide value 550 and use this variable throughout the program;

good organization – good programmer, of course, must be able to organize the various elements of the program. For example, functions should not be placed in different frames, but in one frame of your movie. In addition, try to group functions according to the tasks they perform.

Debugging

All programmers have to debug the programs they create. It is impossible to get the program to work flawlessly the first time you run it. A good specialist should be able to debug the program.

In addition to using the ActionScript debugger, you can debug in a variety of ways. Error messages may appear in the Output window during trial playback of the clip. Sometimes this is enough for you to understand where in the code you have problems 10 .

Program information can also be placed in the Output window using the trace command. It will help you keep track of certain points in the program and the meaning of certain variables at those points.

If you want to use the debugging program, we advise you to study the relevant information in the Flash MX manual. The debugger is a simple tool that allows you to display the values of variables while playing a Flash movie. However, she is unable to perform miracles; a debugging program can only help you figure out your own project.

As a programmer gains experience, he develops his own rules and style. At the same time, it is absolutely not necessary to step on all the rake yourself. By judiciously following the guidelines below will help you avoid many common mistakes. Of course, it is impossible to give advice for all occasions, because it is not in vain that many people consider programming to be an art.

The main goal to strive for is to get easily readable program possibly of a simpler structure. Ultimately, all programming technologies are aimed at achieving precisely this goal, since this is the only way to achieve the reliability of the program and the ease of its modification.

· The program should consist of the most isolated parts, connected to each other only through interfaces. You should clearly separate the interface of a subroutine or module from its implementation and restrict access to information that is unnecessary for their use.

· Each completed action is executed in the form of a subroutine. The size of a subroutine can be different, it depends on the specific action, but it is desirable that its body fit on one or two screens: it is equally difficult to understand a program containing several immense functions, and a scattering of hundreds of subroutines with several lines each. If any sequence of statements is used at least twice, it must also be written as a subroutine.

· All values exchanged between the subroutine and the calling program must be passed to it via parameters. It is preferable to pass input parameters as constants. Usually, in the list of parameters, first write all the input parameters, and then all the output ones. If the subroutine returns one value, it is better to arrange it as a function, if several - as a procedure.

· It is useful in a subroutine to provide a response to invalid input parameters and abort. This may be either printing a message, or, more preferably, generating a result feature. This characteristic must be evaluated in the calling program. The error message should be informative and tell the user how to fix it. For example, if you enter an invalid value, the message must include a valid range.

· Values used only in a subroutine should be declared within the subroutine as local variables. This simplifies program debugging. The use of global variables in subprograms is undesirable because their change is difficult to track.

· Variable names should reflect their meaning. Well-chosen names can make a program somewhat self-documenting. Bad names, on the other hand, are the source of problems. Abbreviations impair readability, and you can often forget exactly how a particular word was abbreviated. The general trend is that the larger the scope of a variable, the longer its name. Before such a name, you can put a type prefix (one or more letters by which you can determine the type of a variable). For counters of short cycles, on the contrary, it is better to get by with single-letter names like i or k.

· Avoid using explicit numbers in your program. Constants must have meaningful names given in the const declaration section. The symbolic name makes the program more understandable, and besides, if you need to change the value of a constant, you only need to change the program in one place. Of course, this advice does not apply to the constants 0 and 1.

· To write each fragment of the algorithm, it is necessary to use the most appropriate means of the language. For example, branching in multiple directions on the value of an integer variable is more beautifully written with a case statement rather than multiple ifs. It's best to use a for loop to iterate through an array. The goto statement is used very rarely, for example. to force exit from multiple nested loops, and in most other situations it is better to use other language features such as break or exit procedures.

· The program must be transparent. If any action can be programmed different ways, then preference should not be given to the most compact and not even the most efficient, but to one that is easier to understand. This is especially important when one person writes the program and others maintain it, which is a widespread practice. "Non-transparent" programming can incur huge costs for finding bugs during debugging.

· Do not place many statements on one line. As in Russian, spaces should be used after punctuation marks:

· Nested blocks should be indented by 3-4 characters, moreover, blocks of the same nesting level must be aligned vertically. Format text in columns wherever possible.

· Mark the end of a long compound statement.

· Use the most appropriate operator to organize loops. The repeat loop is used only in cases where the body will definitely need to be executed at least once, such as when checking input. for loop is used if the number of repetitions is known in advance and the parameter is of ordinal type, the while loop is used in all other cases. When writing iterative loops (in which ratios of variables formed in the loop body are used to check the exit condition), it is necessary provide an emergency exit upon reaching a predetermined maximum number iterations. To make the loop easier to read, we should strive to combine initialization, exit condition testing, and increment in one place.

Some tips for writing branch statements:

· The shorter if branch is better placed on top, otherwise all governing structure may not fit on the screen, making debugging difficult.

· It makes no sense to use an equality check true or false.

· Avoid unnecessary conditional checks.

· If the first branch of the if statement contains a transfer of control, there is no need to use else:

if i > 0 then exit; (here i<= 0 }

· It is necessary to provide for the printing of messages at those points in the program where control should not be transferred during normal operation of the program.

15 rules for writing quality code

There are myriad ways to write bad code. Fortunately, to rise to the level of quality code, it is enough to follow 15 rules. Observing them will not make you a master, but will allow you to convincingly imitate him.

Rule 1. Follow coding standards.

Each programming language has its own code formatting standard, which tells how to indent, where to put spaces and brackets, how to name objects, how to comment code, and so on.

For example, in this piece of code, according to the standard, there are 12 errors:

For(i=0 ;i

Study the standard carefully, learn the basics by heart, follow the rules like commandments, and your programs will be better than most written by graduates.

Many organizations tailor standards to fit their specific needs. For example, Google has developed standards for more than 12 programming languages. They are well thought out, so check them out if you need help with Google programming. The standards even include editor settings to help you follow the style, and special tools to verify that your code conforms to that style. Use them.

Rule 2. Give descriptive names.

Limited to slow, clumsy teletypes, ancient programmers used contracts for variable and procedure names to save time, keystrokes, ink, and paper. This culture is present in some communities for the sake of maintaining backwards compatibility. Take, for example, the language-breaking C function wcscspn (wide character string complement span). But this approach is not applicable in modern code.

Use long, descriptive names like complementSpanLength to help yourself and others understand your code in the future. The exceptions are a few important variables used in the body of a method, such as loop iterators, parameters, temporary values, or execution results.

It is much more important that you think long and hard before naming something. Is the name accurate? Did you mean highestPrice or bestPrice? Is the name specific enough to avoid its use in other contexts for objects that are similar in meaning? Wouldn't it be better to call the method getBestPrice instead of getBest? Does it fit better than other similar names? If you have a ReadEventLog method, you should not call another NetErrorLogRead. If you call a function, does its name describe the return value?

Finally, a few simple naming rules. Class and type names must be nouns. The method name must contain a verb. If a method determines whether some information about an object is true or false, its name must start with "is". Methods that return object properties must begin with "get", and methods that set property values must begin with "set".

Rule 3. Comment and document.

Start each method and procedure with a description in a comment of what the method or procedure does, the parameters, the return value, and possible errors and exceptions. Describe in the comments the role of each file and class, the contents of each class field, and the main steps of complex code. Write comments as you develop the code. If you think that you will write them later, you are deceiving yourself.

In addition, make sure your application or library has a manual that explains what your code does, defines its dependencies, and provides instructions for building, testing, installing, and using it. The document should be short and handy; just a README file is often sufficient.

Rule 4. Don't repeat yourself.

Never copy and paste code. Instead, extract the common part into a method or class (or macro, if needed) and use it with the appropriate parameters. Avoid using similar data and pieces of code. Also use the following techniques:

Create API references from comments using Javadoc and Doxygen.
Automatic generation of unit tests based on annotations or naming conventions.
Generate PDF and HTML from the same markup source.
Getting the class structure from the database (or vice versa).

Rule 5. Check for errors and react to them.

Methods can return error indications or throw exceptions. Process them. Don't rely on the disk to never fill up, your config file to always be there, your application to run with full permissions, memory allocation requests to always succeed, or the connection to never drop. Yes, good error handling is hard to write and makes code longer and harder to read. But ignoring errors simply sweeps the problem under the carpet, where an unsuspecting user will one day find it.

Rule 6. Divide the code into short, separate parts.

Each method, function, or block of code should fit in a regular screen window (25-50 lines). If it's too long, cut it into shorter pieces. Even inside a method, divide long code into blocks, the essence of which you can describe in a comment at the beginning of each block.

Moreover, each class, module, file or process must perform a certain kind of task. If a piece of code performs completely dissimilar tasks, then divide it accordingly.

Rule 7. Use the framework APIs and third-party libraries.

Learn what features are available through your framework's API. and also what advanced third-party libraries can do. If the libraries are supported by your system package manager, then they are likely to be a good choice. Use a code that keeps you from reinventing the wheel (with a useless square shape).

Rule 8. Don't overdo the design.

Design only what is relevant now. Your code can be made fairly generic to support future development, as long as it doesn't become too complex. Don't create parameterized classes, factories, deep hierarchies and hidden interfaces to solve problems that don't even exist - you can't guess what will happen tomorrow. On the other hand, when the structure of the code does not suit the task, feel free to refactor it.

Rule 9: Be consistent.

Do the same things in the same way. If you are developing a method whose functionality is similar to that of an existing one, then use a similar name, similar parameter order, and similar body structure. The same applies to classes. Create similar fields and methods, give them similar interfaces, and map new names to existing ones in similar classes.

Your code must comply with the conventions of your framework. For example, it is good practice to make ranges semi-open: closed (inclusive) on the left (at the beginning of the range) and open (exclusive) on the right (at the end). If there are no agreements for a particular case, then make a choice and stick to it fanatically.

Rule 10 Avoid security issues.

Modern code rarely works in isolation. He has an unavoidable risk of becoming the target of attacks. They don't have to come from the internet; the attack can occur through the input of your application. Depending on your programming language and domain, you may need to worry about buffer overflows, cross-site scripting, SQL injection, and other such issues. Study these problems and avoid them in your code. This is not difficult.

Rule 11 Use efficient data structures and algorithms.

Simple code is often easier to maintain than code that has been modified for efficiency. Fortunately, you can balance maintainability and efficiency using the data structures and algorithms your framework provides. Use map, set, vector and algorithms that work with them. This will make your code cleaner, faster, more scalable, and more memory efficient. For example, if you store a thousand values in a sorted set, then the intersection operation will find common elements with another set in the same number of operations, not in a million comparisons.

Rule 12: Use unit tests.

The complexity of modern software makes it more expensive to install and harder to test. A productive approach would be to accompany each piece of code with tests that check the correctness of its work. This approach simplifies debugging because it allows errors to be detected earlier. Unit testing is essential when you are programming in dynamically typed languages like Python and JavaScript because they only catch any errors at runtime, while statically typed languages like Java, C# and C++ can catch some of them at runtime. compilation time. Unit testing also allows you to refactor code with confidence. You can use XUnit to make it easier to write tests and automate their execution.

Rule 13: Keep code portable.

Unless you have a special reason, don't use functionality that is only available on a particular platform. Don't rely on certain data types (like integers, pointers, and timestamps) to have a specific length (32 bits, for example) because this setting differs across platforms. Keep program messages separate from code, and hardcode culture-specific settings (for example, decimal and integer separators, or date format). Agreements are needed so that the code can run in different countries, so make localization as painless as possible.

Rule 14: Make your code buildable.

A simple command should compile your code into a form ready for distribution. The command should allow you to quickly build and run the necessary tests. To achieve this, use an automated build tool like Make , Apache Maven , or Ant . Ideally, you should set up an integration system that will check, build, and test your code whenever it changes.

Rule 15: Put everything under version control.

All your elements - code, documentation, tool sources, build scripts, test data - should be in source control. Git and GitHub make this task cheap and hassle-free. But many other powerful tools and services are also available to you. You should be able to build and test your program on a configured system by simply downloading it from the repository.

Conclusion.

By making these 15 rules part of your daily practice, you will eventually create code that is easier to read, well tested, more likely to run correctly, and much easier to change when the time comes. You will also save yourself and your users a lot of headaches.

I also have manuals on programming, even on program design and development, also in 1C, something is posted here.

I used to work as an assistant professor at an institute (however, before teaching, I was an administrator, I dealt with 1C, worked a little in a franchise, but didn’t earn much). After 5 years of teaching, now for 6 years a professional 1Snik. Six years later, this publication inspired me to add something.

I saw different students and teachers, programmers and bosses. I myself learned the basics of programming from childhood on my knee, I didn’t finish the courses, but taught like this - I compiled textbooks and articles from the Internet, watched, showed and made video courses, though I used more and more ready-made practical tasks. By occupation, a programmer after college and at an age there is no longer a special opportunity to learn a lot, so I am a programmer from a trench, at first I was engaged in more and more operational activities, I was a lot on user support, which was not particularly useful, what I taught and what I taught, since in the first place is not even quality, but the volume and speed of development, and, accordingly, the ability to achieve a positive result in 100 percent of cases. Even if you made a mistake in the routine - the user will write or call and show himself, all this is eliminated without problems in the working mode. A very useful thing in the organization of work on the support of Bitrix, document management with applications for IT. Now, if it is incorrect to develop a project methodology or not fully thought through, this is where the problem can be much more serious.

Somehow it turned out that they didn’t ask me for venerable certificates, but the first head of the 1Snik department was my Developer with a capital letter, who was distinguished by deep knowledge of the subject area and the ability to do absolutely everything necessary in the work, even in the admin part, everyone respected him very much. There was not a single issue that he could not solve at the enterprise.

Programmers also encountered people-dictators over us, conflicting, stubborn, unwilling to cooperate, listen and share responsibility (instruct or help), hear or convey information, thinking only about limiting personal responsibility in any way interfere with the work of the enterprise. The best boss is not talked about (c) Chinese wisdom.

In project activities, knowing the basics of IDEF modeling and reading SAP ARIS helps most of all (but drawing ARIS diagrams is laborious). In any case, and above all, it is imperative to start projects with a well-thought-out TOR, because without it, understanding and communicating with the project customer is very difficult to develop.

And programming, what is there, 7 operators and an object model ... It is also appropriate that the article is so short. Most of all, it turned out to be necessary to use me for my intended purpose as 1Snika - to learn the configurations used at the enterprise, learn how to help employees, help accountants, understand the code, look for errors in accounting ... And of course, in production in the field of programming, even in operational activities, especially as a rule, there are several systems (accounting, warehouse, transport, ...), complex tasks.

About 5-7 years ago, I formulated a set of rules that guided me when working on projects (mainly automation of enterprise management), and plus, in the same spirit, I tried to teach my subordinates (as a project manager). Today I stumbled upon these rules, read them, shed a tear :) Over time, views change and I don’t quite agree with some rules, which once again suggests that compiling such lists is a thankless task. And yet, when you are inside the subject area (let me remind you - enterprise automation), you encounter daily design errors, then these rules are quite reasonable, understandable and applicable in real situations. And from the point of view of a non-programmer or a programmer from another industry, some of the rules will surely sound pathetic, trite, or meaningless. So I'm not sure that everyone will understand, but I'll publish it anyway.

The first rule of a programmer

Divide and rule.
(© presumably Gaius Julius Caesar)

Meaning: divide a large problem into small ones and solve them one by one. However, remember the problem as a whole: all small decisions must eventually lead to solving the big problem.

The second rule of the programmer

Better to lose a day, but then fly in five minutes.
(© Eagle from the film "Wings, legs, tails")

The sign of a good programmer is the automation of his own activities.
(© ibigdan)

There is never enough money and time to do everything right. But in order to redo it later, both time and money are found.
(© Law of Cheops)

Meaning: it is not enough to successfully complete the task, you need to exit it with new baggage. Create not only final solutions, but also methods + tools - all this will come in handy in this and future projects. Do it even if you're pressed for time, because if you're not growing, you're falling behind. The customer and boss don't care, you don't.

The third rule of the programmer

Read The Fucking Manual
(© desperate sysadmin)

Knowledge of certain principles easily compensates for ignorance of certain facts.
(© Helvetius)

Imagination is more important than knowledge. Knowledge is limited. Imagination covers the whole world.
(© A.Einstein)

Meaning: You must be able to fly high and dive deep. Be able to see the problem as a whole and be able to disassemble it to the smallest detail. Without systems thinking and an analytical mindset, there is nothing to do in programming.

The fourth rule of the programmer

Look at the root.
(© Kozma Prutkov)

There are not so many entities as there are views on them. The essence is the basis of the solution, a look at it is refinement for a specific task.
(© ibigdan)

Meaning: for example, “director” is not a person, it is a position that a person can hold (or no one can hold). And "Ivanov Pyotr Sidorovich" is not a person, but a surname, name and patronymic, that is, the attributes of a person. A person is a body, living or dead, with a bunch of attributes :) Usually, designing does not go down to such nuances, so most automated control systems are very inflexible.

Fifth rule of the programmer

Answer the question "what is it?" - Get a term. Answer the question "why?" - make sense. Perhaps the question "what is the best way to do this?" no longer have to answer.
(© ibigdan)

The essence of programming is to disassemble the subject area into small pieces (analysis) and recreate it in a computer in the form of a working model (synthesis).
(© ibigdan)

Meaning: All programming comes down to alternating analysis and synthesis. Moreover, the analysis can be mathematical, functional, object - any. And the language of synthesis also does not matter. It is only important to understand and competently perform these two stages.

The sixth rule of the programmer

Meaning: if an entity appears in an automated system more than once, then you seriously messed up when designing. Example: "Ivanov Petr Sidorovich, position: doctor, place of work: urological department." Then he has a heart attack and wow! - object number two: "Ivanov Pyotr Sidorovich, patient, cardiology department." In fact, this is one and the same person, but the system is listed as two different, unrelated. Moreover, this is a typical and elementary design error, but there are much more complicated ones. Most CMS consist of such errors more than completely.

The seventh rule of the programmer

Meaning: Multiple meanings. Do not rush to rejoice at the found solution, perhaps it takes into account entities, but does not take into account connections. Old solutions may not work on new tasks of a different scale. In general, you can’t tell about scaling problems.

The eighth rule of the programmer

Consequence: a universal software product is several orders of magnitude more complicated than a specialized one, since it covers a group of interrelated areas.
(© ibigdan)

Consequence: a software product that can do everything is infinitely complex, and therefore impossible in principle.
(© ibigdan)

Meaning: alas, no one will give you the resources to find the answer to "the main question of life, the universe and finally." Look for compromises between what you want and what is possible.

The ninth rule of the programmer

When automating organizational management based on the use of computers, it should be remembered that the main guarantee of its success is a fundamental change in the traditional technology of organizational management.
(© V.M. Glushkov)

Automation is not an end in itself, but a tool for optimizing the activities of an enterprise. If automation does not optimize, then there is no need for it.
(© ibigdan)

Meaning: there is no greater idiocy than automating paper workflow, creating its exact copy in a computer. Some programmers want to make a “user familiar” interface so much that they draw paper sheets on the screen, place lines and signs on them in the same form as they were on paper invoices, etc. From a marketing point of view, this is justified, but this has nothing to do with automation - there used to be chaos on paper, now there is chaos in a computer network. We must not forget that a document is not an entity, but an “accounting view” of it, an entity is the goods listed on the invoice, this is a real object, operations with it must be automated. Paper workflow is just an attempt at "automation" that was made a hundred years before you and before the advent of computers, you don't need to automate it, you need to replace it. It was an example, there are plenty of such moments in any field.