Tag Info

Hot answers tagged

190

Depends on that one line. If the line is readable and concise by itself, the function may not be needed. Simplistic example: void printNewLine() { System.out.println(); } OTOH, if the function gives a good name to a line of code containing e.g. a complex, hard to read expression, it is perfectly justified (to me). Contrived example (broken into multiple ...


166

Testing code that does lots of things is difficult. Debugging code that does lots of things is difficult. The solution to both of these problems is to write code that doesn't do lots of things. Write each function so that it does one thing and only one thing. This makes them easy to test with a unit test (one doesn't need umpteen dozen unit tests). A ...


95

Is it because there is no formal input argument? It is because the output depends on something that is not an input, namely the current time. Why is the actual time of day not treated as the "input to the function" Because you didn't pass it as a parameter. If you did pass it in as a parameter, the function would become an identity function on ...


79

I could overload the constructor so that order [of the parameters] doesn't matter... But is that a good idea? No. Having different constructor overloads will have the opposite effect of what you are intending. The programmer coming after you expects different overloads to have different behavior, and will ask: "What sort of different behavior is being ...


57

You can't create a pure function called random that will give a different result every time it is called. In fact, you can't even "call" pure functions. You apply them. So you aren't missing anything, but this doesn't mean that random numbers are off-limits in functional programming. Allow me to demonstrate, I'll use Haskell syntax throughout. Coming from ...


55

Yes, splitting long functions is normal. This is a way of doing things that's encouraged by Robert C. Martin in his book Clean Code. Particularly, you should be choosing very descriptive names for your functions, as a form of self-documenting code.


45

Yes, this can be used to satisfy best practices. For instance, it is better to have a clearly-named function do some work, even if it is only one line long, than to have that line of code within a larger function and need a one-line comment explaining what it does. Also, neighbouring lines of code should perform tasks at the same abstraction level. A ...


44

First, the "self-calling functions" aren't actually self-calling. I know that's what people in the Javascript community call them, but it's really misleading; the functions never reference themselves, and in fact a lot of the time there's no way to call that particular function more than once. If they were actually self-calling functions, then recursive ...


33

As people pointed, this improves readability. A person reading process_url() may see more clearly what is the general process to deal with URLs just by reading a few method names. The problem is that other people may think those functions are used by some other piece of the code, and if some of them need to be changed they may choose to preserve those ...


30

C++ can have non-method functions just fine, if they do not belong to a class don't put them in a class, just put them at global or other namespace scope namespace special_math_functions //optional { int math_function1(int arg) { //definition } }


30

I've never seen a guideline, but in my experience a function that takes more than three or four parameters smells like one of two problems: The function is doing too much. It should be split into several smaller functions, each which have a smaller parameter set. There is another object hiding in there. You may need to create another object or data ...


30

In theory, loose function-data coupling makes it easier to add more functions to work on the same data. The down side is it makes it more difficult to change the data structure itself, which is why in practice, well-designed functional code and well-designed OOP code have very similar levels of coupling. Take a directed acyclic graph (DAG) as an example ...


29

I think that in many cases such function is good style, but you may consider local boolean variable as alternative in cases when you don't need use this condition somewhere in other places e.g.: bool someConditionSatisfied = [complex expression]; This will give hint to code reader and save from introducing new function.


29

Using a dict let's you translate the key into a callable. The key doesn't need to be hardcoded though, as in your example. Usually, this is a form of caller dispatch, where you use the value of a variable to connect to a function. Say a network process sends you command codes, a dispatch mapping lets you translate the command codes easily into executable ...


29

Would I be correct in assuming that your "parse" function not only parses the code but also executes it at the same time? If you wanted to do it that way, instead of storing the contents of a function in your map, store the location of the function. But there's a better way. It takes a bit more effort up-front, but it yields much better results as ...


28

Should boolean methods always take the affirmative form, even when they will only ever be used in the negative form? Making rules about such things seems a little much -- I wouldn't want to see a guideline in a coding standards document that says thou shalt not use negative names for boolean properties. But as a matter of personal style, I think ...


28

Code organization is all about displaying enough information to convey a single idea. The sweet spot is getting your code pared down enough that a single idea can fit in a single unit of code. Your unit of code can be a function, a class, etc. These are merely tools of organization. As with any tool, it can be over used or used incorrectly. Having a one ...


26

Instead of number of lines, the criteria I would use is that each function should do only one thing and does it well.


24

I always try to give my variables and functions great names. If I can't think of a great name, I'll settle for a good name. If I can't come up with a good name, I'll use an okay name. I have never, in 15 years of professional programming, been unable to come up with a decent name.


21

Revised Answer OK, I see what you mean. I wouldn't call those "self-calling functions" -- the first thing that comes to mind is "immediately invoked functions". "Module" would also work, but I'm not sure how readily it would be understood. Rather than talking about "self-calling" and "non-self-calling" functions, I'd document the script by explaining ...


21

I've seen an increasing trend in the programming world saying that it is good practice to separate code blocks into their own functions. I wouldn't have called this an "increasing trend". I was taught that splitting overly large methods into smaller methods improved readability ... ummm ... nearly 40 years ago. And I was taught the design-time ...


20

Features are what the sales people sell. Functions are what the programmers develop.


19

In addition to Peter's answer, if that condition may need to be updated at some point in the future, by having it encapsulated the way you suggest you would only have a single edit point. Following Peter's example, if this boolean isTaxPayerEligibleForTaxRefund() { return taxPayer.isFemale() && (taxPayer.getNumberOfChildren() > 2 ...


19

sin(x) will always return the same value, as long as x stays the same. Today() could return different results over time because it depends on values outside of your control. For example, if something beyond the control of your program changes the system's internal $current_datetime while your program is running, Today() will suddenly yield different results. ...


19

Virtual methods are commonly implemented via so-called virtual method tables (vtable for short), in which function pointers are stored. This adds indirection to the actual call (gotta fetch the address of the function to call from the vtable, then call it -- as opposed to just calling it right ahead). Of course, this takes some time and some more code. ...


19

IMHO your colleague is correct for the above example. Your preference might be terse, but its also less readable and therefore less maintainable. Ask the question why bother writing the function in the first place, what does your function 'bring to the table'- I have to understand what it does and how it does it, in great detail, just to use it. With his ...


18

An old thumb rule is that a function should be entirely visible on screen, without the need of scrolling. The basic idea is that, if you can't look at the whole function at a time, the function is over complex, and you should split it in more basic pieces. While this rule is very practical and useful, the formal rule is that you should keep only a single ...


17

It's nearly impossible to not be able to think of a name for an artifact you want to design. You may not like what name you come up with because it isn't concise or sexy, but if you think too hard, you'll end up with a poorly named artifact. Let's say you have something that helps you construct objects, but you don't know this is typically called a factory. ...


17

As longs as it's clear from the name, comments and signature of the function that its purpose is to generate output, there's nothing wrong with it. What's not good is to have output generation as a side effect of a function that also does something else (like compute and return some data, or write a file), because that's a flagrant violation of the single ...


17

Speaking strictly, a procedure is a subroutine that is executed purely for its side effects (like printing something to the screen) and returns no values. A function is a subroutine that always returns the same value given the same inputs and has no side effects. A method is a procedure or function that is associated with a class or object. The confusing ...



Only top voted, non community-wiki answers of a minimum length are eligible