Related
My understanding of "Spaghetti Code" is a code base that jumps from one block of code to another without an logical and legible purpose. The most common offender seems to be the GOTO statement.
I'm currently reading/referencing the function chapter of Clean Code: A Handbook of Agile Software Craftsmanship. The author, while self admittedly, is extremely strict on the size of functions. I understand the idea of keeping functions small, however, he suggests they should be around 5 lines. While Classes certainly become more legible, I'm afraid of creating spaghetti code by writing smaller functions. Smaller functions also seem to inadvertently create much higher abstractions as well.
At what point does code become spaghetti code? How abstract is too abstract? Any answers would be greatly helpful.
As an aside, I'm a long time follower of Stack Overflow although this is my first time posting a question, so any suggestions regarding my post are welcome as well.
Thanks a lot!
As already said in the comments, there is no absolute rule. At the end, you should aim for a good readability of your code. But that is not all about the length of your methods. Robert Martin suggests ordering the methods according to the degree of abstraction. Abststract methods should be at the top of your class, and the more a method is, the deeper it should be located.
Another importand aspect is the method name. It should be chosen well in order to make clear what the method does! If you choose your method names wisely, then comments should be hardly necessary. For example, consider an if-statement:
if(isValidAge(value)) {
...
}
is much more readable than
if(value > 10 && value < 99) {
...
}
because the intention of the statement becomes much clearer. Of cause you could add a comment in the second example. But comments often become outdated (there is an extra chapter in Robert Martin's book about that). I think, this style of programming leads to many short methods.
It is hard to choose the right level of abstraction. According to my expecience, it is easier to start with a low level of abstraction. So I can first concentrate on solving the problem well. When I need more abstraction later, I still can refactor the code. TDD helps a lot!
Hope, this helps ...
I agree with comments and answers here. From practical point of view the thinks which Robert Martin writes in his books are every time very good orientations and I try to get as much close as possible to this "rules" and indeed 5-lines-methodes are mostly not to bad.
In my eyes best way to avoid spaghetti code is to write (small) classes with a high Cohesion. The disadvantage is that you become a whole bunch of classes, which makes it sometimes a little bit more hard for new employees to come in the project.
I understand the idea of keeping functions small, however, he suggests they should be around 5 lines.
That sounds ideal :)
While Classes certainly become more legible, I'm afraid of creating spaghetti code by writing smaller functions.
Spaghetti code is caused by code jumping from place to place with (having different levels of abstraction in the same function - low-level IO code and high level application logic). If you extract small functions, your result is getting further away from spaghetti code, not closer).
At what point does code become spaghetti code?
When the code forces you (the programmer) to make mental jumps (switch contexts) from line to line, the code is spaghetti code. This is true whether you use GOTOs or not (but GOTOs can make the problem much worse).
I want to parse a HTML text and find special parts. For example a text in 3rd div of 1st row and 2nd column of a table. I have 2 options to parse: Regular Expressions and XPath. What is advantages and disadvantages of each one?
thanks
It somewhat depends on whether you have a complete HTML file of unknown but well-formed content versus having merely a snippet or an expanse of HTML of completely known content which may or may not be well-formed.
There is a difference between editing and parsing, you see.
It is one thing to be editing your own HTML file that you wrote yourself or are otherwise staring right in the face, and you issue the editor command
:100,200s!<br */>!!g
To remove the breaks from lines 200–300.
It is quite another to suck down whatever HTML happens to be at the other end of a URL and then try to make some sense out it, sight unseen.
The first calls for a regex solution — the very one shown above, in fact. To go off writing some massively overengineered behemoth to do a fall parse to set up the entire parse tree just to do the simple edit shown above is quite simply wrong. It’s also its own punishment.
On the other hand, using patterns to parse out (as opposed to lex out) an entire HTML document that can contain all kinds of whacky things you aren’t planning for just cries out for leveraging someone else’s hard work intead of recreating the wheel for yourself, and badly at that.
However, there’s something else nobody likes to mention, and that’s that most people just aren’t competent at regexes. They don’t really understand them. They don’t know how to test them or to craft them. They don’t know how to make them readable and maintainable.
The truth of the matter is that the overwhelming majority of regex users cannot even manage as simple and basic a thing as matching an arbitrary HTML tag using a regex, even when things gotchas like alternate encodings and CDATA sections and redefined entitities and <script> contents and archaic never-seen forms are all safely dispensed with.
It’s not because it’s hard to do; it isn’t, actually. It’s just that the people trying to do it understand neither regexes nor HTML particularly well, and they don’t know they don’t know, and so they get themselves in way over their heads more quickly than they realize. And then they have a complete disaster on their hands.
Plus it’s been done before, and correctly. Might as well learn from someone else’s mistakes for a change, eh? It would probably help to have a few canned regexes at your disposal to go at frequently manipulated things. This is especially useful for editing.
But for a full parse, you really shouldn’t try to embed a full HTML grammar inside your pattern. Honest, you really shouldn’t. Speaking as someone has actually can and has done this, I unlike 99.9999% of the responders here the credibility of actual experience in this area when I advise against it. Sure, I can do it, but I almost never want to, and I certainly don’t want you to try it at home unsupervised. I can’t be held responsible for any damage that might ensue. :)
Sure, this may sound like “Do as I say, not as I do,” but if your level of regex mastery were at a level that allowed you to contemplate such a thing, you would not be asking this question. As I mentioned, almost no one who uses regexes can actually match an arbitrary HTML tag, simple as that is. Given that you need that sort of building block before writing your recursive descent grammar, and given that next to nobody can even manage that simple building block, well...
Given that sad state of affairs, it’s probably best to use regexes for simple edit jobs only, and leave their use for more complete solutions to real regex wizards, for they are subtle and quick to anger. Meaning of course the regexes, not (just) the wizards.
But sure, keep some canned regexes handy for doing simple editing rather than full parsing. That way you won’t be forced to redevise them each time from first principles. I do keep a few of these around, but then I also keep simple frameworks that allow me to edit a particular structural element of the HTML, like the plain text or the tag contents or the link references, etc, and those all use a full parser, letting me then surgically target just the parts I want in complete confidence I haven’t forgotten something.
More as a testament to what is possible than what is advisable, you can see some answers with more, um, “heroic” pattern matching, including recursion,
here,
here,
here,
here,
here, and
here.
Understand that some of those were actually written for the express purpose of showing people why they should not use regexes, because some of them are really quite sophisticated, much moreso than you can expect in nonwizards. That difficulty may chase you away, which is ok, because it was sort of meant to.
But don’t let that stop you from using vi on your HTML files, nor should it scare you away from using its search or substitute commands. Don’t let the perfect be the enemy of the good. Sometimes good enough is exactly what you need, because the perfect would take more investment than it could ever be worth.
Understanding which out of several possible approaches will give you the most bang for your buck is something that takes time to learn, and no one can tell you the answer that works for you. They don’t know your dataset, your requirements, your skillset, your priorities. Therefore any categorical answer is automatically wrong. You have to evaluate these things for yourself.
I think XPath is the primary option for traversing XML-like documents. With RegExp, it will be up to you to handle the different forms of writing a tag (with multiple spaces, double quotes, single quotes, no quotes, in one line, in multi-lines, with inner data, without inner data, etc). With XPath, this is all transparent to you, and it has many features (like accessing a node by index, selecting by attribute values, selecting simblings, and MANY others).
See how powerfull it can be at http://www.w3schools.com/xpath/.
EDIT: See also How do HTML parses work if they're not using regexp?
XPath is less likely to break if the web developer does any minor changes. That would be my choice.
Here is the canonical Stackoverflow explanation for why you should not parse HTML with regex:
RegEx match open tags except XHTML self-contained tags
In general, you cannot parse HTML with regex because regex is not made to parse HTML. Just use XPath.
It's good to split code up into functions and classes for modularity / decoupling, but if you do it too much, you get really fragmented code which is also not good.
What is the golden rule for when to split code up into functions?
It really does depend on the size and scope of your project.
I tend to split things into functions every time there is something repeated, and that repetition generalized/abstracted, following the golden rule of DRY (Do not repeat yourself).
As far as splitting up classes, I tend to follow the Object Oriented Programming mantra of isolating what is the same from what is different, and split up classes if one class is implementing more an one large theoretical "idea" or entity.
But honestly if your code is too fragmented and opaque, you should try considering refactoring into a different approach/paradigm.
If I can give it a good name (better than the code it replaces), it becomes a function
I think you generally have to think of a chunk of codes have a chance of being reuse. It comes with experience to figure that out and plan ahead.
I agree with the answers that concentrate on reusability and eliminating repetition, but I also believe that readability is at least as important. So in addition to repetition, I would look for pieces of code (classes, functions, blocks, etc.) that do more than one thing.
If the name associated with the code does not describe what it does, then that is a good time to refactor that code into units which each have a single responsibility and a descriptive name. This separation of concerns will help both reusability, and readability.
Useful code can stick around for a long time, so it is important that you (or ideally someone else) can go back and easily understand code that was written months or years before.
Probably my own personal rule is if it is more than 2 lines long, and is referenced more than once on the same page (ASP.net), or a few times spread over a couple of pages, than I will write a function to do it.
I was taught that anything you do more than once should be a function. Anything similar should have a parent class, and above all else consult your source code "standards" within your organization. The latter mostly deals with formatting.
First, write the feature you're adding. (Notice the word "First", we tend to write a function/class before writing the feature, which might lead to having too many fragmentation).
Then, review the code you just wrote/changed, find what blocks of the code that is:
3-lines or more, and..
repeated, and..
Can be grouped under a named function. Because code is written by us, people (not programs), to be read/changed later by us, people (not programs).
This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
How many lines of code should a function/procedure/method have?
I would like to know how many lines of code should be function have? How many lines is too much.
I read this a while back, it around 10 or 20 lines but it was because the screen would only accommodate so many lines. Now as the screen size become larger, that would not hold true.
Let's assume that the no part of the function is used anywhere else i.e. disregard DRY principle.
I'd like to hear what others have to say about this.
thanks.
Note: Duplicate of When is a function too long?, could not find it when I posted.
Lines are irrelevant, but complexity is.
A function should do one task, and it should be readily apparent. It shouldn't take you more than a few moments to understand exactly how and what the function does.
This kind of question is well answered in Code Complete. Steve McConnel wrote an entire page to answer this question. His conclusion:
Decades of evidence say that routines
of such length (>100 lines) are no
more error prone than shorter
routines. Let issues such as the
routine's cohesion, number of decision
points, number of comments needed to
explain the routine, and other
complexity-related considerations
dictate the length of the routine
rather than imposing a length
restriction per se. That said, if you
want to write routines longer than
about 200 lines, be careful.
It should have as many as it needs.
I don't see any point in restricting a function line-count to screen size (ok to be fair, I didn't start programming until after screens could accomadate more than 10-20 lines - maybe this did make sense in some environments). Just write the function as it makes sense to. When it gets so large that pieces of code start repeating, refactor those pieces to other functions/classes/components.
It's a pretty arbitrary rule of thumb. Some like 20 lines, others like the no-scroll rule. In the end, just make sure it's readable and easily understood at a glance. Read over your SOLID principles and make sure the method has only 1 responsibility, etc.
As long as necessary, as short as possible.
I take 5-10 Lines as a rule of thumb but if there is some logic that can't be (re)factored easily into multiple functions i write longer where necessary. On the other hand i often have functions that are just a line or two long.
If you do not immedatly understand what a part of code does, write a new function for it.
I don't think it matters how many lines it has...as long as it's efficient.
Any code that can be reused anywhere in your codebase should be moved to another function/method in the same class or a shared class and called.
I've heard the screen size metric before too but obviously not intended to be a hard limit or to scale with monitor size. It's just intended to convey the principle of DRY and that keeping functions as small as possible is one of the best ways to write code that can scale (in project size).
The Linux Kernel Coding Style document says:
Functions should be short and sweet,
and do just one thing. They should
fit on one or two screenfuls of text
(the ISO/ANSI screen size is 80x24, as
we all know), and do one thing and do
that well.
Now, I realize this is in the context of kernel code, but I think some of the points it makes re: function length are generally valid. Find a copy here. The section on functions is Chapter 4.
All in all, function length shouldn't be constrained by some artificial rule; factor stuff out if it makes sense, and because it makes stuff easier to read, but the rule about 1-2 screens is not written in stone.
this is just an opinion from an oo-perspective:
i prefer to keep my methods in logical units of work and dont really care about metrics like LoC. this makes it also quite easy to properly name your methods, and keeps them from getting bloated.
a very trivial functional example would be instead of having a function that calculates the fibonacci sequence inline in a loop i would add a successor(int a,int b) function, that gets called by the fibonacci() function.
a more complex example in oo fashion would be a http client that performs a GET request. i'd break that up into something like this:
Connection getConnection(String host, int port)
Request createRequest(String[] params)
void sendRequest(Request r)
String getResponse(Connection c,Request r)
Functions should be exactly small enough to do their job, but no smaller.
When a piece of code is commented we say just that, it's "commented out".
But when it's not commented out, what is that?
Uncommented isn't quite the same. Active?
It's definitely not commented in.
What's the best way to refer to the act of de-commenting out code?
Uncommented is the most common word for that.
I call code which isn't "commented out" simply "code"
Visual Studio has a function called "Comment out the selected lines".
The opposite function is called "Uncomment the selected lines". I use the term "uncommented."
A couple possibilities:
Live code
Legacy code
I wish it were "uncommented in."
I use "revived" or "restored" for code that used to be commented out, but no longer is. I use "live" or "uncommented" for code that's intended to be compiled or executed.
If it was once commented out in the past, then by uncommenting it it will become
Decommented.
(You can recomment it if you want but I won't recommand that..)
If it was never ever commented out, it's just
code.
These are, to me now, the several different (*) states a Live code can have. (Or maybe it's just yoda english.)
*: implicit potential meta- [add your latin-born term here :P].
It's just a piece of un-out-commented, un-disabled, un-erased, un-inactivated, un-unused, un-deprecated, un-obsolete, un-rewritten, un-archived code.
Or, in layman's terms, code.
Think of an editorial document. Its kind of like saying "what is the un-deleted writing called?" Just, the writing.
Although it is widely used to refer to 'live' code, 'Uncommented code' is an ambiguous term.
It could refer to code that was once commented out, but has been edited to allow it to be run, or it could refer to code that has no descriptive comments.
I call commented out code...poor code. If it is to be commented out then just toss it all together. Your version control system should keep track of the various states of your previous work. Rather than commenting it out for others to figure out why it was commented out later doesn't seem to be a good coding practice!
Seeing how many disparate answers exist for this question, there are a few things you should do.
Pick a term and stick with it.
Consistency is most important. It's okay if it's not the best one ever, and you can change your choice if a more obvious term appears in the distant future.
Explicitly describe that term to your teammates.
Don't just say, "it means uncommented, or whatever you call it." Don't just say, "it's the opposite of commented." Tell them that it means code that was previously commented out, and has now had its commenting syntax removed. Tell them that this code is now active and will execute when called. Never assume that your team is smart enough to "just get it" just because they nod when you use the term.
As a subjective answer, I use the term uncommented. It's a bad name for the behavior, but at least it's mildly intuitive. It beats nonsense like unhashed for languages that use the # character for comments.
I honestly do say "commented in". In phrases like "well, it works with that line commented out, so let's comment it back in and re-run the test". "Uncomment" would be more correct, but sounds clunkier. I wouldn't use that expression in formal writing, though, just when talking to my pair.
During a debugging session, I often comment and uncomment lines of code.
From a purely semantic (and yes, anally pedantic) perspective, it's the action that's described by the phrase, not the code.
"Commented Out" is a verb describing the action whereby a statement was turned into a comment to remove it from the code that's acted upon by the language's parser.
Code having been subjected to the opposite action, that of taking a comment and turning it into a statement to include it in the code that the language's parser acts upon, would be "Statemented In". But of course that's ridiculous.
That said, I agree with Andrew that outside of a transient debugging session, before it's committed, code should be removed if it's not used and not left around in comments to confuse things.
The problem is with the term "commented out". It's an abuse of the comment feature of most languages. In C/C++ you should use the preprocessor to conditionally compile your code, perhaps like the following:
#if 0
...
... here is the code that is not in the build
..
#endif
...
... here is the code that is in the build
...
I recall a coding standard in a place I used to work at used "#ifdef NOT_DEF" and a few other symbols in place of "#if 0" to add some semantics to the "commented out" block.
The terms used under this scheme were "included" and "excluded" code, though "included" was usually assumed when talking generally about "the code".
Of course, not all modern languages have such a preprocessing feature, so you're back to abusing the comment feature.
I ended up going with commented code being code under comment and normal code being code not under comment. The action being take code from under comment or bring out from under comment.
We call it 'unremd'. You won't find it in the dictionary but it is the opposite of REM(d) and most importantly has fewer syllables...