10 Ways to Customize Code::Blocks
Code::Blocks comes with default settings that are the most natural for most C++ applications; however, as you start spending more and more time in the environment, you may find that Code::Blocks can be a friendlier place with just a few tweaks.
Use tab character
Or more specifically, don’t use tab character. This setting doesn’t make any difference if you’re working on a project in which everyone will always be using Code::Blocks. The problem with tab characters, however, is that different editors tend to interpret tabs differently. Some editors move the cursor to the next tab stop, some editors move the cursor over some number of characters, and not all editors agree on how many characters to allocate for a tab. Fortunately all editors interpret spaces the same so it’s much safer to tell the Code::Blocks editor to always use spaces and never save tabs in the source files. To do so, select Settings→Editor. Now select General Settings on the left and make sure that Use TAB Character is unchecked.
Syntax highlighting changes the colors of different types of structures, using one color for keywords, a different color for variable names, a third for character strings, and so on. This is very helpful in avoiding silly errors as you’re typing. For example, if you misspell a keyword, it will not appear in the keyword color. To enable this feature, select Settings→Editor→Syntax Highlighting. Normally Code::Blocks can tell the language from the extension of the filename. If you are using a non-standard file extension, be sure to add it to the list by selecting Filemasks. In addition, you can adjust the syntax highlighting options from this window to better fit your needs. This is particularly important if you have some form of vision problems, especially any form of color blindness.
Source code formatter
This might be old fashioned, but a good programmer should show a little pride in the appearance of his code. This requires the creation and steady adherence to a coding standard. Even more than that, when working on a large team, everyone should use the same coding standard. Otherwise, the code looks messy, as modules written by one person have one look and feel while those written by a teammate have a different look — very unprofessional.
Forcing adherence to a coding formatting standard is easy in Code::Blocks. Its code editor will reformat your code to fit any desired standard.
The Code::Blocks source code formatter won’t adjust variable names. Even worse, it won’t touch your program logic. So if you write crummy code, don’t blame it on the Code::Blocks editor.
Select Settings→Editor and then select Source Formatter from the list that appears to get a window that looks like Figure 1. The preview window shows you what your choices will look like in practice. This example follows the ANSI standard, but you may choose from among many other common standards, or you can select Custom and then click on the Indentation and Formatting tabs to create your own standard.
Once you’ve selected a standard, the editor will try to coax you into using that standard. For example, if you enter if (true) and then hit Enter, the editor will put the cursor at the indented location below the if. If you then enter an open brace, the editor will back you up, place the brace in line with the i in if, jump to the next line, and indent over.
Even better, once you’ve finished coding, if you select Plug In→Source Code Formatter (AStyle), the editor will go through your module and reapply the current source code standard. So if your work mate wasn’t quite as careful with his programming as you were, not to worry — a few mouse clicks and it’s all cleaned up.
This is a weird option. If you code a lot (read: a lot!), code abbreviations can save time, especially if you’re not a very good typist. Code abbreviations allows you to enter some code word and then hit Ctrl+J, and voila, the Code::Blocks editor will enter the corresponding predefined template that you then fill in.
For example, if you were to enter class in the a copy of Code::Blocks and then entered Ctrl+J, Code::Blocks would first ask you for the name of your class and then it would fill in all the stuff shown in Figure 2.
Code::Blocks comes with a set of abbreviations already defined, but you can add all the abbreviations you want by choosing Settings→Editor and then selecting the Abbreviations option on the left side of the window.
The good thing about code abbreviation is that it can save a lot of typing and automatically enforces the source code formatting standard that you select. Very fast typist (or would that be keyboarder?) may not get a lot out of this feature, but if you don’t use all ten fingers when you type or are otherwise just slow on the keyboard, you probably want to try using this feature.
Code::Blocks has this cool feature called AutoComplete. After you’ve typed in some minimum number of letters (the default is four, but you change that), if you pause in your typing, Code::Blocks will look for all of the things that start with those letters. In this way, Code::Blocks can anticipate what it is that you’re trying to say.
For example, in the Budget5 program that is included with the downloadable material from Dummies.com, if you enter Acco and then pause just a half second (that’s not very long!) then a window pops up as shown in Figure 3 that offers the only two things that Code::Blocks knows about in this program that start with Acco: the class Account and the typedef AccountPtr. Since you meant Account, you can just hit Enter and it will fill this in for me.
In this example, you’re creating a pointer to an Account called pAcc. When you next type in pAcc-> and then pause, Code::Blocks opens a window listing the public members of Account as shown in Figure 4.
This is an interesting feature when referring to your own classes. More than anything, selecting from the list means that you don’t type in the function name wrong or misspelled.
This feature really becomes interesting when you enter an object that’s defined in a library. For example, if you enter cout., you will get a list of the public members available to the cout object. This can be really helpful when you don’t have documentation or you just don’t know where to start.
Enable all warnings
Enabling all warnings is a no brainer. Mistakes that pop up at compile time are much easier to find (duh!) and fix than those that you have to go hunt for yourself at run time. That’s why the C++ syntax is so picky — it wants to make sure that you have coded exactly what you intended before it goes off and creates an executable that does something completely different.
There are a few things, however, (quite a few things, actually) that GNU C++ compiler will fix and continue on without comment, if you want it to. For example, it’s not an error to define a variable in a function and then never use it. Or to put a return in the middle of a function so that the lines of code after the return can never be executed. These are not errors, but they do look mighty odd to a mistrustful compiler.
The GNU compiler will generate a warning if it sees either of these two cases or any of dozens of other suspicious constructs in your code. You should go over every warning to make sure that you understand what the compiler is complaining about and why. Try to fix the problem if you can but understand it even if you choose not to fix it.
Warnings will uncover a lot of mistakes that are about to become bugs in your programs.
Creating a new build target
The Code::Blocks environment allows you to create more than one build target. A build target allows you to create a separate executable with unique build settings. For example, you would definitely want to include symbol information in the executable that you use for debug but not in the one that you intend to ship to customers (see below for more).
You can most easily create a Debug build target and a Release build target when you create the Project — let the wizard do all the work for you. However, it very often happens that after weeks of working on and debugging a project, you go to release it only to find that there’s no Release build target. Not to worry, you can always create a new build target on your own.
To create a new build target, select Project→Properties, then select the Build Targets tab. You will see something that looks like Figure 5, which shows the Budget5 program with a single Debug build target.
Use the following steps to create a Release build target:
Select the Debug target and click on Duplicate.
Enter the name of the new build target, Release.
Change the Output File Name to binReleaseBudget5.exe and the Objects Output Directory to objRelease.
Click on Build Options to set whatever build options that you want for this particular target and click OK.
You will definitely want to turn symbol information off and turn optimization on.
Click on OK to save the new build target.
To build a particular build target, select Build→Select Target, and then choose from the available targets. This directs Code::Blocks as to which executable you want to create when you select build.
Project — enable optimizations
You might think that each line of C++ code generates a set of machine instructions without regards to the lines of code around it, and in non-optimized mode you would be right. The optimizer built into the GNU compiler can generate a more efficient program from your C++ source by looking across multiple lines of code.
Consider the following trivial and completely made up (but clever) example:
// i++; MOV EAX, i[BP] INC EAX MOV i[BP], EAX // fn(i) MOV EAX, i[BP] PUSH EAX CALL FN
Here the line i++ was converted into the three lines of machine code that follow:
Load the value of i into the EAX register.
Increment the EAX register.
Store the incremented value back into i.
The next line converts the call fn(i) into the following.
Load the value of i into the EAX register.
Push the value of EAX onto the stack.
Make the call.
Notice that Step 4 is actually unnecessary. There’s no need to load the value of i into the EAX register because the value is already there from Steps 1, 2, and 3. Even a mediocre optimizer would notice this fact and not generate the second MOV EAX, i[BP].
This isn’t much of a savings, but this example is easy to understand, even if it’s not such a great improvement. You would need to be a real whiz at assembly language to understand most of the optimizations that the GNU compiler makes.
You can enable optimizations for a particular build by selecting Project→Build Options, then selecting the Release build on the left and selecting one of the optimization options.
Technically, there are several optimization options because the optimizer can take a lot of time. If you have a very large project, there isn’t much point in spending a lot of time optimizing a module that won’t be executed very often. For small to medium-sized projects, just enable full optimization — you won’t notice the extra few seconds it takes to compile.
You can enable this option for all builds by selecting Settings→Compiler, then selecting the Compiler tab and selecting one of the Optimize cases; however, this isn’t such a good idea. Don’t enable optimization in the Debug release of the project if you plan on using the debugger. The changes to the code that the optimizer performs will make the program appear to jump around in a semi-random walk when you try to step through it.
Project — disable the debugger symbols
Symbol information is included in the executable solely for the use of the debugger. This information should not be included in the version that you ship out to users: It increases the size of the executable needlessly and, worse yet, it releases dangerous information to hackers should one be trying to find a vulnerability in your program.
To disable debug information in the Release build target, select Project→Build options, and then select the Release target on the left. Now make sure that the Produce Debugging Symbols [-g] option is clicked off for the Release target. (Now’s a good time to make sure that this same option is clicked on for the Debug build target.)
Project — setting a program’s arguments
Some programs are meant to be executed with command line arguments. Code::Blocks provides the following mechanism for providing command line arguments when executing such a program from within the Code::Blocks environment:
Select Project→Set Programs’ Arguments.
Select the build target in the upper window.
Enter whatever you like in the Program Arguments window.
Select OK to close the window.
When you enter Start or Run, Code::Blocks will supply these arguments to your program.