Replies: 12 comments 10 replies
-
Originally posted by Drew Hammond on 2014-12-07T00:59Z Somebody give that man a medal |
Beta Was this translation helpful? Give feedback.
-
Originally posted by Mahder on 2015-02-04T22:01Z Just love how you presented these concepts....simple and down to the point! Perfect! |
Beta Was this translation helpful? Give feedback.
-
Originally posted by Larry on 2015-02-21T03:28Z "the number of ACYCLIC execution paths" acyclic: not displaying or forming part of a cycle. In other words: An execution path through the code (routine or block) that does not cycle back and execute the same code along a different path based on variable or state changes. This begs the question of: How does one count the N-path of a feature having cyclic (e.g. not acyclic) loops? Moreover, note that putting an "a" in front of the word is a means of saying "not". It stems from ancient Greek (and other languages) as well as semitic languages like Hebrew, where "a" is aleph (or alpha in Greek). See WikiPedia on Alpha, which contains the following: Privative a is the Ancient Greek prefix ἀ- or ἀν- a-, an-, added to words to negate them. It originates from the Proto-Indo-European *n̥- (syllabic nasal) and is cognate with English un-. Thus, in English, we might say: uncyclic, which is not a word, but you get the idea. |
Beta Was this translation helpful? Give feedback.
-
Originally posted by Larry on 2015-02-21T03:45Z Also---I will point out that measuring acyclic execution paths or N-path is not as straight-forward or simple as it might seem. However, if you learn to pay attention to the matter, your code will improve! Nevertheless, there is an 80% value you can get with 20% effort! Whatever routine or block of code you are examining will be one of two flavors:
In the case of #1, the work is pretty simple. One examines the code, finds the calls with arguments and states that will execute each conditionally-controlled pathway. In doing so, one will write tests that "prove" the code performs as required by its specification (you do have one of those don't you?). In the case of #2, the work is much more challenging and tedious! For each client call (e.g. routine component-call), one will isolate the called routine first, exercising it with N-Path tests, working one's way down the call-stack towards routines that fit condition #1 (above). Each #1-conditioned routine will have its own tests that reasonably exhaust the N-paths. I say reasonably because exhaustive may not be humanly possible! Once one handles the bottom layer of #1-conditioned-routines, then one can come up a layer in the call-stack. At the next layer up, the necessity for being extremely thorough will diminish, as one has proven the supporting layer in greater detail. However, there are some interesting facets to note as we rise up in the call-stack! First, one may find that doing the work of proving lower layers makes suggestions about poor or improper design of the upper. Perhaps the upper layer routine calls are mutually exclusive of each other? This might suggest that they get pulled out into their own routine and the upper layer routine is done away with completely. Second, the conditions that control which lower-layer calls are made are essentially "contracts" or stateful conditions that say, "This routine is only legal to call under these circumstances of state!" In a language with Design-by-Contract (e.g. Eiffel, D, .NET, et al), such things will suggest controlling contracts in the lower-layer routines, and even invariants in the enclosing class. Third, now that the underlying routines are satisfactorily tested, the upper layer calling routine may only need to be spot-checked with primary N-path use-case calls, and the exhaustive approach can be relaxed. Finally, what one must note about all of this is how it literally defies the ruthless dogma of the TDD religion that states that one MUST write a failing test first and then one can write the code! This presumes that one is writing from an exhaustively detailed design, wherein one understands the complete scope and nature of the routine and code and the job it is to perform from the start. Reality tends to say this: 80/20 rule---that is---even with the best of planning, design, instruction, research, and so on, one may yet only ever expect to know 20% of what a job fully takes from the beginning, and learns the remaining 80% along the pathway to completion! Writing software is a messy human and imperfect business. We do well and better to not treat it with undo pride, which suggests that we know all as we code: If that were true, we would need no testing, no proving, no refactoring, and we would encounter no bugs and no flaws, eh? Cheers!! |
Beta Was this translation helpful? Give feedback.
-
Originally posted by Ben Derisgreat on 2015-07-31T21:39Z Thanks for the explanation! A bit annoying that PHPMD will count null coalescing toward the NPath complexity. 7 null coalesces already reaches to 156000 complexity. |
Beta Was this translation helpful? Give feedback.
-
Originally posted by Jessica Mauerhan on 2015-09-18T17:25Z I just took a function that was 600+ lines, and started with an N-Path of 1478464112885979 (That's 1.4 quadrillion) and got it under 200. It took 3 hours, but now we'll be able to maintain that code a lot easier. |
Beta Was this translation helpful? Give feedback.
-
Originally posted by David Kaštánek on 2016-01-13T18:28Z Excellent explanation! Thanks :) |
Beta Was this translation helpful? Give feedback.
-
Originally posted by denis631 on 2016-11-04T13:28:43Z Great article. Short and straight to the point! |
Beta Was this translation helpful? Give feedback.
-
Originally posted by Zoltán Göndös on 2018-03-08T13:54:52Z Highest I have ever seen is: NPath Complexity is 177,570,312,241 (max allowed is 200). No joke. It was real. |
Beta Was this translation helpful? Give feedback.
-
Originally posted by Ahsaan Ansari on 2018-12-13T05:41:58Z One of the finest article i found till now, great man thanks a lot. |
Beta Was this translation helpful? Give feedback.
-
Originally posted by Harsha Jadhav on 2019-07-24T06:06:01Z Great contribution, really appreciate it. Simple, to the point and actionable. |
Beta Was this translation helpful? Give feedback.
-
Originally posted by Basil Bear on 2020-02-13T10:22:22Z Perfect Niklas, thank you- you put it down very clearly. I now have a fuzzy feeling of "enlightenment" :) |
Beta Was this translation helpful? Give feedback.
-
npath-complexity-cyclomatic-complexity-explained/
NPath complexity and cyclomatic complexity explained
https://modess.io/npath-complexity-cyclomatic-complexity-explained/
Beta Was this translation helpful? Give feedback.
All reactions