CodeCity . A city represents a code base. Each class is represented as a building. The aspect of a building gives information on the corresponding class. For example: the color is the number of lines, the height is the number of methods and the width is the number of attributes.
System Complexity View and Class Blueprint . Like CodeCity the color and shape represent various attributes. An added benefit compared to the codecity is that you can also show links between the code elements. For example inheritance or invocation.
NDepend  for .NET also has many interesting code diagrams.
The fact that we're still typing crap into windows and calling advances along this one-dimensional path 'innovation' is pain.
Intentional had a lot of promise but was too slow off the mark and now feels more like BPML, which has too much XML hiding under the covers to be good. As it stands, making solution development easier for business users has not had a broad impact on the overall productivity of developers.
'Blub' assumes existence on a continuum of language. It's a limiting concept in itself, as many of us have a different internal representation of thought.
It's sad to read about "python stuff for swift" or "haskell stuff for scala" when the only advantage of those exercises is as homework to understand the concepts.
I meant not as an unrealized idea but as in generally, a good idea. I did check out the software but unfortunately it's not for commercial use. Still, neat way of analyzing code.
Clarificatory comments, thumbs up! Code that requires an accompanying multi-chapter essay to understand, thumbs down.
Looks like about 150 words of comments there, not a multi-chapter essay.
That aside, I don't know what this code is doing, but working on sundry avionics software I would find that approximate amount of commentary very helpful in some situations. I would be remiss to downplay the value of this commentary without reading the actual words.
First, incorrect documentation is harmful. So much so that in many circumstances I'd rather have no documentation than incorrect documentation. If all of your code has such a high comment-to-logic ratio you're either writing some really subtle (perhaps math-heavy) stuff, or you're introducing a bunch of potential for documentation issues.
Second, readability counts. If you feel like your code isn't understandable without a large number of comments, you've probably not written it to be readable. Sometimes this is very difficult to do (yes, I'm looking at you hot-path C++ code!) but I think that past a certain point effort can be better spent making the code easier to understand than on verbose documentation.
Yes tests. But people can 'fix' tests at the same time too.
In codebases, the ratio of big to small matters. It's fine to have some of those classes that seem too small. They are a natural consequence of good structuring. As well, it's okay to have a few large classes also, ones that you know could be broken down but not convincingly.
The thing that's awful is that if you say this sort of thing people want to believe that it's license to allow classes and methods to grow without bound, but it isn't. If you aim for understandability, you'll have code with sizes that fall into a distribution, usually power-law-ish
From what I understood, and by reading the comments, it seems like there are certain patterns in code that could be somewhat-universally flawed? Like seeing a lot of indentation without meaningful code in between?
Or am I getting this wrong? Is it really possible to establish a "score" of sorts for how the code looks without actually looking at what it does?
If it is, then it would seem like an interesting idea to build a code "shape-analyzer" that would give you the same type of analysis. Or is this too hard to describe in terms of patterns that we can see but can't explain?
I think I need my morning coffee... am I making any sense?
I ask this because I think I could do it with my own, but not sure if I could with another one's. Or maybe to the odebase of a particular product instead?
Shapes are really just for illustration, but they also emphasize the irony: “you’re part of a preternaturally enlightened dev team” yet you review your coworkers' code without even reading. Perhaps there's something to be read between the lines. :)
You go talk to your boss and tell them you are taking indefinite sick leave, because if it takes you two hours to realise you can't read the screen you are clearly not accomplishing anything by going to work, you are probably either physically ill or severely burned out, and you will therefore need at least some relaxation time and possibly some medication or therapy to switch your brain back on.
It resembles something I've heard graphics designer do when they try to appreciate the information hierarchy or the contrast on a creation, without being disturbed by the meaning of words of symbolic value of graphical elements.
Although, I disagree about comments. I mostly overcomment code, because sometimes, a project lacks a proper specification and it's sometimes the only place where to explain what you actually do.
Maybe it's just the way the article is organized, or maybe I gave up reading the "I don't like this" examples before I got to one that said "This is good".
Love this part, seconded.
And yes, ckdarby's comment of getting a redundancy plan in place for your glasses is spot on.
I often think along the same lines when reading code. (Except exhibit 3—but I'm starting to arrive at it.) I also see my own past mistakes there.
> middle is used to decide which users we need to send emails to
Yeah but no, you can't do that with text color.