The SitePoint Forums have moved.

You can now find them here.
This forum is now closed to new posts, but you can browse existing content.
You can find out more information about the move and how to open a new account (if necessary) here.
If you get stuck you can get support by emailing forums@sitepoint.com

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Assuming that the arguments represent properties of a file I would create a class to represent the file. Then I would use individual setters for each property of the file. This would be separate from the class that handles the file object. From your example that seems like what your trying to accomplish. On a generic level the decision can't be made without knowing the purpose of the method(s). I always make this decision based on scope and purpose.

What are the parameters for? You can't tell, it's opaque. With a fluent API, they become obvious.

Your not going to use setters/getters for every function you make in your project just so you can tell what they are for.

There are 2 ways to know what they are:
#1 search the documentation (yes, i know, i hate it also)
#2 use a good IDE that searches the documentation for you, and as you type, it will tell you. Some good IDEs will tell you what the parameters are from your own comments (custom functions), and even go to that function's declaration if you control+click that function.

There are 2 ways to know what they are:
#1 search the documentation (yes, i know, i hate it also)
#2 use a good IDE that searches the documentation for you, and as you type, it will tell you. Some good IDEs will tell you what the parameters are from your own comments (custom functions), and even go to that function's declaration if you control+click that function.

You're assuming the documentation is up to date and in sync with the code. I'd much rather have readable code that says what it does than incomprehensible code and superb documentation. It just makes things easier, both for the developer and for the user.

The reason why I came up with this question is because I was going through some old code of mine. I used to cram as much possibilities into one function.
Which ended up in a few boolean arguments... But I thought that was the way to go, showing what I could do...
Going through that code again afterwards I had to go and search my function lists to figure out what exactly was going on in there. That's why I suddenly started doubting. Code I wrote less than a year ago had become annoyingly unreadable.

Apparently the struggle in my own brain is also a point of discussion between people and from what I can see it really comes down to personal preference and there is no general rule towards this.

But the problem with this approach is that there will be a lot of define statements to 'dirty up' your code.

Thanks for all the reactions people

EDIT:

Originally Posted by oddz

Assuming that the arguments represent properties of a file I would create a class to represent the file. Then I would use individual setters for each property of the file. This would be separate from the class that handles the file object. From your example that seems like what your trying to accomplish. On a generic level the decision can't be made without knowing the purpose of the method(s). I always make this decision based on scope and purpose.

It is actually a function in my form handling class to upload file uploads

Actually, no! ( ) I've been doing quite a bit of C++, and because of the way that you lay methods out (simply listing them in the class definition and actually defining them in a source file), it's tempting to add more and more methods for common functionality. I suppose previous Java programming may have had some role there.

In fact, it's been very useful. It's amazing how much quicker writing applications is once you have written methods for many common tasks.

Of course, the enableFileLock/disableFileLock is only useful when it's certain what you want to do, which is why the other setFileLock is available for when you want to set it depending on an outcome.

Jake Arkinstall
"Sometimes you don't need to reinvent the wheel;
Sometimes its enough to make that wheel more rounded"-Molona