1. 9

  2. 2


    This is one of The Most Important web sites in all of Software Engineering.

    People really really really do need to understand what this is, why it is one helluvah problem, and how to combat it at every stage.

    1. 2

      Connascence is directly related in computing to degrees of encapsulation.

      My problem is with the web page headline that says “Connascence is a software quality metric & a taxonomy for different types of coupling.” I argue that it is not a software quality metric at all, because there is no widely accepted way to formally determine such a metric.

      Even the originator of the term (in relation to software) Meilir Page-Jones, states that “I have taken a lot of flak over the last few years for using it.” [1] He stated that using the alternate terms of coupling or interdependence, evoked different meanings in programmers minds for historical reasons, and hence he promoted a different term connascence, in order to distinguish from them.

      [1] Meilir Page-Jones, Fundamentals of Object-Oriented Design in UML (1995), Page 227

      1. 2

        In my oppinion, connascence should be kept in mind when designing a programming language or a public API or protocol, but if you’re worrying about connascence when trying to implement a new feature in an application, your only making things harder on yourself.

        Unless you want your productivity to quickly grind to a halt, code should be written in such a way that it is easy to change. That means taking the simplest and most direct approach. Once clear patterns arise in the code you have already written, then you should compress the common code by introducing a sub-procedure or function. If you’re trying to design intra-application API’s that minimize connascence you’re waisting time, because you don’t know how your going to use the API yet. You’ll end up not needing functions and data you’ve provided, and/or needing functions and data you didn’t provide.

        This need for pervasive and wide-spread change in application code is why staticly typed languages have a huge advantage in terms of productivity.

        1. 3

          code should be written in such a way that it is easy to change. That means taking the simplest and most direct approach.

          Once the code base is on the wrong side of a few hundred thousand lines of code… Your words take on a stronger, harsher meaning.

          written in such a way that it is easy to change.

          As the code base gets big, way way way bigger than you possibly can hope to read and understand, that translates to..

          “How little do I need to read and understand to make a valid and safe change to this code base?”

          As the code base grows, coupling, direct and connascent, dominate all other considerations.

          Why? Because you must read and understand the implications of change on everything the code you are trying to modify is coupled to.

          Direct coupling is sort of nice, your tools will tell you about it, and you can nail down the semantics of the interface.

          Connascent coupling is a total nightmare, as your tools won’t tell you about it, your integration tests might (if you’re lucky), but your customers will.

        2. 1

          I’ve never heard of this. The name is confusing. The first few examples…

          “Connascence of name is when multiple components must agree on the name of an entity. “

          “Connascence of type is when multiple components must agree on the type of an entity.”

          “Connascence of meaning is when multiple components must agree on the meaning of particular values. “

          It seems like there’s a more intuitive term than connascence out there. If abstracted, it looks like SharedAttributes where attributes are name, type, and meaning. It does look interesting as a list of potential screwups. A few are pretty fundamental like meaning, algorithm, and order. Some others you might cheat around but maybe the cheats themselves are indicating their importance.

          @JohnCarter, would you elaborate on your very, different reaction to this site? I’m guessing you’ve put some thought into it. :)

          1. 2

            One of the most important design principles in terms of modularisation, is that you should aim to reduce the coupling between modules, and increase the cohesiveness within modules.

            We normally think about Coupling between modules in the very limited form, of declarations of symbols, and references to them, where the declarations are in one module and the reference in another.

            ie. The syntactic level of coupling.

            The word “Connascence” means “Grew up together”.

            And refers to the sorts of coupling that arises between modules, when the modules “grow up together”.

            Have you ever taken a krufty bit of old code and tried to reuse it for something different…. and then found everything just plain hurts? There is some undocumented order in which methods must be called, some hidden state that has to be initialized in some undocumented manner, or global state that gets corrupted by the re-use….

            Congratulations, you were bitten by connascent coupling.

            Very very common in krufty legacy systems.

            Have a look at the “Other Resources” page for more on the origins or the term.

            Why is it so so important to understand?

            Because when people complain that software is not re-usable, or is fragile, or is brittle, most of the time the problem comes down to some form of connascent coupling.

            1. 1

              That makes sense. I get the concepts but just never heard of the term. I’ll look into it further.