deWiTTERS Coding method – deWiTTERS (2023)

(This article was translated asSerbo-CroatiancrossJoanna Milutinovic）

This tutorial describes the coding style I've developed over the years. My style is not very broad. In fact, I don't know anyone close to my weird way of programming. But I like it and wanted to share it with you anyway (good luck bastard!). I use it for various programming languages: C, C++, Java, C#, Python...

If you just want to have a quick look at the style, scroll down to the bottom of this page and see how I rewrote some of the source code into my WiTTERS style, that should give you a quick idea of ​​how nice it looks.

Why adopt a coding style?

Every developer uses a certain style, some are good, some are bad. A coding style can give your code a uniform look. You can make the algorithm clearer or more complex. There are two main reasons for a particular coding style:

1. Develop clean, readable code so that someone else can quickly understand it when they have to dig into it. More importantly, when you go back to old code written a year ago, you don't start thinking "I don't remember being lost...".
2. When working in a team, it's best to have everyone use the same style so that your code has a consistent look.

Since I developed most of the code myself, I don't have to think about another reason. And because I'm stubborn, I won't inherit other people's styles. That's why my style is fully optimized to produce clean and readable code.

basic rules

I've tried to cover the most important aspects of coding style in the following rules.

1. Everything should be as easy to understand as possible.
2. All content must be as legible as possible, unless it conflicts with the above rules.
3. Everything should be as simple as possible, unless it conflicts with the rules above.

The best way to think about these rules is to keep everything as simple as possible, unless it affects comprehensibility or readability. Or to quote Albert Einstein:

Make everything as simple as possible, but not simple.

As a developer you should always try to follow the above rules even if you don't follow my coding style.

With the advent of modern programming languages, it is possible to write understandable and readable code. Gone are the days when programming was done entirely on-board. Therefore, my style tries to be as close as possible to our natural language. You could almost say that my code reads like a book. This is probably also why my code is poorly documented. I can barely connect! I even think that the discs are "bad" (and not in the cold sense of the word). Only when I do something weird do I add a comment explaining why. IMHO comments should never say what your code does, let your code say what it does.

Any fool can write code that a computer can understand. Good programmers write code that people can understand.

fuller martin

identity card

Let's start with the most important coding style topic: identifiers. All identifiers, as well as the rest of the code and comments, must be written in English. It is not uncommon for software projects to move from one person to another, from one company to another located on the other side of the world. So write everything in English, because you never know where your code will be next.

variable

Variable names must be in lowercase, with words separated by an underscore. It is the most similar to our natural script and therefore the most readable. Underscores simply replace spaces in our usual way of writing. A variable named "RedPushButton" cannot be read as easily and quickly as "red_push_button", which I press.

If you want your variables to be easy to understand, you should give them obvious names. Obviously, all variables represent some kind of "object" or "value", so name them accordingly. Don't waste your time with jkuidsPrefixing vndskaVariables ncqWith ksldjfYour nmdsadType because it's neither understandable nor clean. If you have an "age" variable, it is obviously a short int or unsigned. If "filename", then it must be a string. easy! Sometimes some variables are easier to understand if they include a type, like GUI buttons like "play_button" or "cancel_button".

There are some prefixes and suffixes that improve the readability of variables. Here is a list of the most common:

hay_

Use them for all boolean values ​​so that there are no errors in your type. It's also great for if statements.

It is_

All global variables start with "the_", making it clear that there is only one.

_counting

Use _count to indicate the number of elements. Do not use plurals like "bullets" instead of "bullet_count" because plurals will represent strings.

Arrays or other variables representing lists must be written in the plural, such as enemies, walls, and weapons. However, it is not necessary to do this for all types of arrays, as some arrays are not actually lists of elements. Some of them are "filename char[64]" or "byte buffer[128]".

permanent end

Constants or word endings should always be capitalized, with underscores separating the words for readability, such as MAX_CHILDREN, X_PADDING, or PI. This usage is widespread and confusion with ordinary variables should be avoided.

You can use MAX and MIN in constant names to indicate value limits.

tip

The type defines the classification of the variable. It's a pretty abstract term, so we can't use English as a reference for writing them. But we definitely need to distinguish them from other identifiers. So for types I use UpperCamelCase. Use UpperCamelCase for any class, structure, enumeration, and other content that may precede a variable declaration.

Name the type in such a way that you can use the same name for generic variables, for example:

help window help_window;
file header file_header;
armas armas[MAX_WEAPONS];

Flow diagram of the procedure

if more if more

There are several ways to write if statements. Let's start with braces. There are 3 main methods of placing brackets:

if(condition) if(condition) if(condition)

I've never seen English text with brackets like in the first example, so why would we encode it like that? The words are just not separated properly. The second example puts parentheses with the condition instead of the if statement, and the parentheses are actually part of the if statement instead of the condition, so the last example is the best. This latter approach also has the advantage of gaining a better understanding of the structure of the prosthesis.

if (!((dob > 12) && (dob < 18))) if( !((dob > 12) && (dob < 18)) )

Personally, I would write this code differently, but this is just to show you an example.

How are braces managed now? Do not use them! Unfortunately, C, C++, Java or C# do not support this, only Python does. So we can't just remove them, instead what we can do is put curly braces to make it look like a clean, simple Python program:

if(condition) { statement; } else if( condition) { statement; } else { statement; }

When the condition becomes too long, you must break the line. Try splitting it before the operator and where the state is less relevant. Align the next line with the previous line and use indentation to display nested structures. Do not put parentheses after the condition, in this case put them on the next line to clarify the subblock.

if( (actual_major_version < MIN_MAJOR_VERSION) || (current_major_version == MIN_MAJOR_VERSION && current_major_version < MIN_MINOR_VERSION) ) { update(); }}

You can omit the curly braces when there is only one statement after the if statement, but be sure to put the statement on the next line unless it is a return or break.

if(bullet_count == 0) recargar();if(a<0) return;

although

While loops are written in the same way as if statements. I use 4 spaces for each indentation.

while (condition) { statement; }

For a do-while loop, put the while on the same line as the closing parenthesis. That way, there is no confusion whether the time period is at the end or beginning of the subblock.

do { statement; while (condition)

for

The only purpose of a for loop is to repeat. That's what they do! You can always replace the for loop with a while loop, but don't. Try using "to" when repeating some items, and if that doesn't quite work, use "while". The "for" structure is very simple:

for( int i = 0; i < MAX_ELEMENTS; i++ ) { 语句; }

Use i, j, k, l, m to iterate over numbers and "it" to iterate over objects.

to change

The structure of the Switch statement is similar to the structure of if and while. The only thing you need to consider is the extra recess. Also leave extra space after the breakpoint.

change(variable) { case 0: statement; interruption; case 1: statement; interruption; default: break; }

Function

Functions do things, and their names should be self-explanatory. So it always includes a verb, without exception! Use the same name as the variables, meaning all lowercase words are separated by an underscore. This allows you to write neat little phrases in your code that anyone can understand.

Also check that the function does what its name says, no more, no less. So if you have a function called "load_resources", make sure it only loads resources and doesn't do any other initialization. Sometimes you're tempted to quickly initialize things in load_resources because you've already called it from a higher level, but that will only get you into trouble. My deWitters style uses very few comments, so the function should definitely do what it says on the tin. When a function returns something, make sure its name makes it clear what it returns.

Some functions come in "yin and yang" pairs and you should be consistent in your naming. Some examples include get/set, add/delete, insert/delete, create/destroy, start/stop, increase/decrease, new/old, start/end, first/last, up/down, next/previous, open/close , Load/Save, Show/Hide, Turn On/Off, Resume/Pause, etc.

Below is a simple function call. As with the if statement, use spaces after the opening curly brace and before the closing curly brace. You can also leave a space after the comma, as is done in English.

do_something(with these arguments);

When a function call becomes too long, you need to split it into multiple lines. Aligns the next line with the previous one, makes the structure visible, and breaks after a comma.

HWND hwnd = CreateWindow( "MyWin32App", "Cool App", WS_OVERLAPPEDWINDOW, my_x_pos, my_y_pos, my_width, my_height NULL, NULL, hInstance, NULL);

definition

The following is an example of a function definition:

bool do_something_today(with this parameters) { get_up(); go_to(work, car); job(); go_to(home, car); sleep(); return true; }

Be careful not to make your functions too long. Or to quote Linus:

The maximum length of a function is inversely proportional to the complexity and level of indentation of the function. So if you have a conceptually simple function that's just one long (but simple) case statement where you have to do lots of little things for lots of different cases, it's fine to have a longer function. However, if you have a complex feature and you suspect that a less talented freshman won't even understand what it's about, then you should stick more strictly to the maximum limit. Use helper functions with friendly names (if you think it's performance critical, you can ask the compiler to include it and it will probably do a better job than you).

a course

I use the same capitalization for class names as I do for types. Don't bother adding a "C" in front of every class, it's just a waste of bytes and time.

As with everything, give your classes clear and obvious names. So if the class is a subclass of the "Window" class, name it "Main Window".

When creating a new class, remember that everything starts with a data structure.

Data rules. Algorithms are almost always self-evident if you choose the right data structures and organize things well. At the heart of programming are data structures, not algorithms.

Fred Brooks

heritage

"is a" relationships must be modeled using inheritance and "has a" relationships must be modeled using constraints. Be careful not to abuse inheritance, it's a great technique, but only if it's applied correctly.

member

You should definitely distinguish between member variables and normal variables. If you don't, you'll regret it later. They can be called m_Member or fMember. I prefer to use my_member for non-static members and our_member for static members. This way you get nice sentences in the method body, like

if( my_help_button.is_pressed() ) { our_screen_manager.go_to( HELP_SCREEN); }

Otherwise, everything that applies to naming variables also applies to members. One problem I haven't been able to solve so far is Boolean terms. Remember that "is" or "has" must always be included in a Boolean value. Combined with "my_", you get crazy things like "my_is_star" and "my_has_children". I haven't found the perfect solution yet, so if you have any suggestions, please leave a comment below this article!

You may not declare class members as public members. Sometimes it seems faster to implement and therefore better, but my God, are you wrong (as I have been many times before)? You must access class members through public methods.

method

Everything that applies to functions also applies to methods, so always include a verb in the name. Make sure the class name is not included in the method name.

code structure

Aligning similar lines can give a better overview of your code, for example:

int object_verts[6][3] = { {-100, 0, 100}, {100, 0, 100}, { 100, 0, -100}, {-100, 11, 100}, (100, 0, -100}, {-100, 0, -100} }; rectangle RECT; rectangle.left = x; rectangle.top = y; rectangle.right = rectangle.left + width; rectangle.bottom = rectangle.right + height;

Never put multiple statements on the same line unless you have a good reason to do so. One reason for this could be that dummy lines can be drawn for clarity, for example:

si( x & 0xff00 ) { exp -= 16; x >>= 16； } si( x & 0x00f0 ) { exp -= 4; x >>= 4； } si( x & 0x000c ) { exp -= 2; x >>= 2; }

Related variables of the same type can be declared in shared declarations. This makes the code more compact and provides a better overview. But never declare unrelated variables in the same declaration!

integer x, y length integer;

imenski prostor, paket

Namespaces or packages must be written in lowercase letters without underscores. Use namespaces for each module or layer you write so that the different layers are clear in your code.

to design

When I start a project, I don't do a lot of initial design. I just have a global structure in my head and start coding. Like it or not, code will evolve, so give it a chance to evolve.

Code evolution means rewriting bad code, and after a bit of programming, your code will be bad. I use the following rules to keep the code well structured.

1. When a function becomes too large, break the problem into several smaller helper functions.
2. If a class contains too many members and methods, split part of the class into a helper class and include the helper class in the main class (don't use inheritance for this!). Make sure that your helper classes do not reference or use the parent class for any operations.
3. When a module contains too many classes, split it into multiple modules, where higher-level modules use lower-level modules.
4. When you're done with a feature or fix a bug, review the entire file you changed to make sure everything is in perfect shape.

Some projects can get big, very big. One way to deal with this growing complexity is to separate projects into different layers. In practice, layers are implemented as namespaces. The upper layers use the lower layers. Therefore, each layer provides functionality to the upper layer, and the upper layer provides functionality to the user.

document

Files must be named according to the classes they contain. Don't put multiple classes in one file so you know where to look when you're looking for a specific class. The directory structure must represent a namespace.

the structure of the .h file

A C or C++ header file shows the implemented interface. This is key knowledge when designing the layout of .h files. In a class, first define a "public" interface that other classes can use, then define all "protected" methods and members. In this way, the information that is most important to the person using the class is displayed first. I don't use private methods or members, so all members are grouped at the end of the class declaration. This gives you a quick overview of the course content at the bottom. Group them according to the meaning of the method.

/* * Zaglavlje licence */ #ifndef NAMESPACE_FILENAME_H #define NAMESPACE_FILENAME_H #include#include "others.h" espacio de nombres dewitters { class SomeClass : public Parent { public: Constructor(); } ~ destruktor(); void javne_metode(); zaštićeno: void protected_methods(); int član_moje_šake; doble i segundo miembro de ; const static int MAX_WIDTH; }; extern SomeClass the_some_class; } #en caso

.java .cs file structure

.java or .cs files do not provide a class interface, they only contain the implementation. Since data structures are more important than algorithms, define members before methods. That way, when you're exploring code, you can quickly learn more about a class through its data members. Similar approaches should be grouped together.

Here's a rough overview of a .java or .cs file:

/* * License header */ package com.dewitters.example; import standard.module.*; custom module import. *; class SomeClass extends ParentClass { public final int MAX_WIDTH = 100; protected int my_first_member; protected double my_other_member; constructor() { } method() { } }

vic

Some people like to have little jokes in their code, while others hate funny things. In my opinion, you can use jokes as long as they don't affect the readability of the code or the performance of the program.

WiTTERS style compared to other styles

Here I will show you the live action code. I stole someone else's code and rewrote it in my own style. You decide for yourself if my style is better. In my opinion, you can read my code faster because it is shorter and all the identifiers are named properly.

If you think the code you see can beat my style, leave a comment below this post and I'll write it in the coolest "deWiTTERS" style and post it here.

Indian Hills stil C

/* *skyblue() * * Determines if the sky is blue. */int/* TRUE or FALSE */skyblue(){extern int time;if (time < AM || time > afternoon)return(FALSE);/*black*/elsereturn(TRUE);/*blue*/ } /* *tail(nodep) * * Finds the last element in the linked list pointed to by nodep and returns a pointer to it. */NODE */* pointer to end of linked list */tail(nodep)NODE *nodep;/* pointer to head of linked list */{register NODE *np;/* current pointer advances to NULL */ register NODE * lp ; /* last pointer following on np */ np = lp = node; while ((np = np->next) != NULL)lp = np;return(lp);}

Rewritten in WiTTERS style:

bool sky_is_blue() { return the_current_hour >= MAÑANA && the_current_hour <= Evening;} Nodo* get_tail( Nodo* cabeza ) { Nodo* cola; } tail = null; node *it; for( it = head; it != NULL; it = it->siguiente ) { tail = it; } return tail; }

"The Code of Commentary" by Ryan Campbell

/* * Summary: Determines attack order and manages each battle * Parameters: Object creature representing the attacker * | A creature object representing the defender * Returns: a Boolean value indicating the success of the battle * Author: Ryan Campbell */ function beginBattle( attacker, Defender ) { var isAlive; // Boolean indicator of whether he is alive or dead after the attack var teamCount; // Loop counter // Preemptive attack check if(defender.agility > attacker.agility) { isAlive = Defender.attack( attacker); } // If still alive, continue original attack if(isAlive) { isAlive = defender.attack(defender); } // See if any defender wants to counterattack for(teamCount = 0; teamCount < Defender. team. length; i++) { var teammate = Defender.team[teamCount]; if(teammate.counterAttack = 1) { isAlive = teammate.attack(attacker); } } // TASK: Handling attacker or defender kill logic return true;} // end battle begin

Rewritten in WiTTERS style:

function handle_battle(attacker, defender) { if (defender.agility > attacker.agility) { defender.attack(attacker); } if( Attacker.is_alive() ) { Attacker.attack( Defender ); } } var i; for( i = 0; i < Defender.get_team().length; i++ ) { var teammate = Defender.get_team()[ i ]; if( teammate.has_countetratack() ) { teammate.attack( attacker); } } // TASK: handling the logic to resolve attacker or defender death}

bartender cohen