Month: August 2015

How many times have you searched in the code base of your company projects to know how a recurrent treatment was implemented? This might concern a technical treatment like the database access, logging, socket access, etc… , or it might concern a design needs like the design patterns implementation. Continue reading “Programming Tip: Tag your source code to assist the developers.”

Robert C.Martin wrote an interesting article about a set of metrics that can be used to measure the quality of an object-oriented design in terms of the interdependence between the subsystems of that design.

Here’s from the article what he said about the interdependence between modules:

What is it that makes a design rigid, fragile and difficult to reuse. It is the interdependence of the subsystems within that design. A design is rigid if it cannot be easily changed. Such rigidity is due to the fact that a single change to heavily interdependent software begins a cascade of changes in dependent modules. When the extent of that cascade of change cannot be predicted by the designers or maintainers the impact of the change cannot be estimated. This makes the cost of the change impossible to estimate. Managers, faced with such unpredictability, become reluctant to authorize changes. Thus the design becomes rigid.

 

Continue reading “Generic programming to fight the rigidity in the C++ projects”

Choosing a software library is not always an easy task, specially if many concurrent libraries exist for a specific need. Many factors could influence a developement team to choose a library, here are some of them:

1- Licensing

The library license is the first thing to check, it’s very important to verify if the license is compatible with your using in your project, before going further and discover the library capabilities.

http://en.wikipedia.org/wiki/Comparison_of_free_and_open-source_software_licenses Continue reading “10 factors to consider when choosing a software library”

Facebook as Google and Microsoft chose to open source many of their  projects which is a good news for many companies and developers. Indeed having access to the source code from big companies is always interesting for many reasons:

• They have resources to employ experts like Andrei Alexandrescu.
• They have resources to  invest in the quality and they refactor regularly.
• The source code is well tested in production as explained by Jordan Delong in its Folly article:

The utilities contained in Folly are things we use heavily in production—this is code that runs on thousands of servers doing work on behalf of 900 million users every day. These utilities are loosely connected, but the over-arching theme for all of the components is high performance at scale. Some of them will show a fairly specialized focus, like reducing contention or packing things into small amounts of memory.

• They have enough feedbacks from the users to improve their projects.

Many  C++ open source projects are available from their GitHub repository. We can enumerate: folly, hhvm, osquery, rocksdb, proxygen, fbthrift and fatal.

Let’s discover some common characteristics of these projects: Continue reading “Some characteristics of the Facebook C++ open source projects.”

In a previous post we talked about the clang-modernize tool to detect where you can use some new C++11 features to modernize your C++ source code.  But how we can easilly detect where the new C++ features are used in a project?

Facebook and Google use intensively C++11 in their source code. Folly from Facebook as we discovered in a previos post use almost all the C++11 features and I was curious to know if Microsoft also use the new  C++11 standards in their open sourced code. Continue reading “Easy way to detect where the C++11/C++14 features are used in a C++ project : WinObjC case study.”

Here’s the common definition of the inheritance from wikipedia:

In object-oriented programming (OOP), inheritance is when an object or class is based on another object (prototypal inheritance) or class (class-based inheritance), using the same implementation (inheriting from an object or class) specifying implementation to maintain the same behavior (realizing an interface; inheriting behavior). It is a mechanism for code reuse and to allow independent extensions of the original software via public classes and interfaces. 

The inheritance is overused in many C++ libraries and every C++ developer must master the inheritance and also the polymorphism mechanism if he chose to adopt the OOP approach. But what’s wrong with the inheritance? Continue reading “With the C++17 Concepts we can say goodbye to the class inheritance”

Static analysis is not only about directly finding bugs, but also about finding bug-prone situations that can decrease code understanding and maintainability. Static analysis can handle many other properties of the code:

• Code metrics: for example, methods with too many loops, if, else, switch, case… end up being non-understandable, hence non-maintainable. Counting these through the code metric Cyclomatic Complexity is a great way to assess when a method becomes too complex.
• Dependencies: if the classes of your program are entangled, effects of any changes in the code becomes unpredictable. Static analysis can help to assess when classes and components are entangled.
• Immutability: types that are used concurrently by several threads should be immutable, else you’ll have to protect state read/write access with complex lock strategies that will end up being un-maintainable. Static analysis can make sure that some classes remain immutable.
• Dead code: dead code is code that can be removed safely, because it is not invoked anymore at runtime. Not only can it be removed, but it must be removed, because this extra code add unnecessary complexity to the program. Static analysis can find most of dead code in your program (yet not all).
• API breaking change: if you present an API to your client, it is very easy to remove a public member without noticing and thus, breaking your clients code. Static analysis can compare two states of a program and can warn about this pitfall.
• API usage: some APIs are intended to be used carefully. For example, a class that hold disposable fields must be itself disposable in general, except when the disposable field lifetime is not aligned with the class instances lifetime, which then sounds like a design problem.

Continue reading “C++ Static analysis: Bug vs Bug-prone situations”

Every  project has its own style guide: a set of conventions about how to write code for that project. Some managers choose a basic coding rules, others prefer very advanced ones and for many projects no coding rules are specified, and each developer uses his style.

The coding style has a big impact on the source code readability, investing some hours to train developers, and doing periodically a code review is always good to make the code easy to maintain and evolve. Continue reading “10 most voted C++ best practices”

Many resources exist talking about the better way to learn a programming language, we can enumerate:

• Reading a book or a magazine.
• Web sites.
• From a collegue.
• Doing a training.

Another more interesting approach is to study a known and mature open source project to discover how their developers implements the code. In case of C language a good candidate could be the  SQLite source code. Continue reading “Learn the “C” programming language by studying real projects: SQLite case study”

The last few years, many experts, magazines, web sites and developers talk about the  C++ revival. This wave was initiated by the new C++11 standards and it may  continue with the C++17 . But is these new standards were adopted by the companies? or just by the community?

If the companies ignore the new C++ features and prefer to move forward to other languages, all the effort to make C++ better will fail and unfortunately the language may die after few years. Continue reading “Based on our feedbacks, the new C++11 standard is not its swan song.”