codes development ideology

CODES Development Ideology

From a codebase perspective, CODES is very verbose. Each network model almost completely defines its own behavior within its own singular source file. As a result there is often a lot of repeated code and behavior that is replicated across various defined network topologies. There are pros and cons to this approach and has been greatly influenced by the type of development that has built up CODES. ROSS is built with pure C; most of CODES is written in C and as such, does not approach development from an object-oriented perspective.

There's no function overloading or generics in C - using void* and casting for everything to get around this limitation frequently can make things very hard to statically (or even dynamically) analyze! Furthermore, it's very likely that two different network topologies might have such different needs that the amount of time and effort at creating a parent class with all possible special case child classes to properly define these different topologies' behavior won't actually make the code any less complicated. And then the behavior is scattered across 10 different files and interface implementations and actually understanding what this network model does becomes much harder to realize.

Within the last 6 years (at time of writing) there have been models (like the 2D Dragonfly Custom model) which utilized C++ and some organizational structures for assisting network behavior have been developed in C++ but with significant restraint. Generally, the use of C++ should only be done if it significantly improves the readability of the code or significantly saves on complexity.

For instance, std::vector is frequently used in the more recently developed Dragonfly networks as it's useful to be able to iterate over these dynamically sized arrays without having to manually keep track of its size. std::map and std::set are also used for their flexibility as creating a set or a hash map for all various keys and structs that may be placed in them would necessitate a significant amount of C code to facilitate and can be difficult for someone not familiar with the pattern to understand.

One of the most important tenets of CODES development going forward (at least from my personal perspective) is code understandability. CODES is complex enough, if something can be implemented in a way that is readable without significant sacrifice in performance, it should be implemented that way. Generally, it would be faster to implement a hash map in C specifically tailored for whatever type of data it's supposed to store than it is to use a generic templated std::unordered_map. But will the 50 or so lines of code dedicated to facilitating the necessary operations (multiplied by however many data types you intend to use this type of structure for) make the model simple to understand? How are these structures tested? What happens if the underlying stored data changes?

So C++ is often used but let's not go crazy with it. If it can be done simply in C, do it that way.