Hot answers tagged

100

Don't overthink this, Range range is fine. I use such kind of naming for more than 15 years in C#, and probably much longer in C++, and have never experienced any real drawbacks from it, quite the opposite. Of course, when you have different local variables in the same scope, all of the same type, it will probably help to invest some mental effort to ...


88

That naming convention is often used when people want to be able to give a variable the same name as its type. For example: Employee employee; Some languages even enforce that capitalization. This prevents having to use annoying variable names like MyEmployee, CurrentEmployee, EmployeeVar, etc. You can always tell if something is a type or a variable, ...


84

The LoC in a method is a completely pointless measure. The important things are separation of concerns and code duplication. A method should only do one thing, and that one thing should be expressed in its name. Other things should be left to other methods. The problems arising from code duplication cannot be overestimated (in other words, they are always ...


82

I use Get when I know the retrieval time will be very short (as in a lookup from a hash table or btree). Find implies a search process or computational algorithm that requires a "longer" period of time to execute (for some arbitrary value of longer).


80

No, long methods are not always bad. In the book Code Complete, it is measured that long methods are sometimes faster and easier to write, and don't lead to maintenance problems. In fact, what is really important is to stay DRY and respect separation of concerns. Sometime, the computation is just long to write, but really won't cause issue in the future. ...


78

I use : initialize() terminate() I find it the more appropriate: it's hard to not see it in code, because it's both long words (I don't use init) it's correct english (AFAIK) in my head, terminate avoids ambiguity. It doesn't match begin (which matches end), start (which matches stop), create (which matches destroy), setup (which matches unset), load (...


77

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.


69

The characteristic of being static is independent of the visibility. The reasons that you will want to have a static method (some code that does not depend on non-static members) will still be useful. But maybe you don't want anyone/anything else to use it, just your class.


68

In .NET, you often have pairs of methods where one of them might throw an exception (DoStuff), and the other returns a Boolean status and, on successful execution, the actual result via an out parameter (TryDoStuff). (Microsoft calls this the "Try-Parse Pattern", since perhaps the most prominent example for it are the TryParse methods of various primitive ...


59

I would say that find may fail but get shouldn't.


59

The methods, properties and constructors (i.e. members of a class) that you define using a public accessor determine the surface area that the users of your class will be allowed to interact with. Any method that you don't want to be part of this surface area should not be made public. Reasons why some members might not be public: They are implementation ...


55

Most of the focus here seems to be around the word always. Yes, absolutes are bad, and software engineering is almost as much art as it is science, and all that... but I'm going to have to say that for the example you gave, the method would be better if it was split up. These are the arguments I'd typically use to justify splitting up your method: ...


52

The only reason I can think of is that dates are immutable objects, so by calling plusDays you're not adding days to the original object but creating a new one with new properties, but that's very vary subtle. This is exactly the reason. Imagine you had some kind of api for manipulating ranges of dates for scheduling purposes. It might expose methods ...


50

Many potential performance concerns are not really a problem in practice. The issue you raise may be one of them. In the vernacular, we call worrying about those problems without proof that they are actual problems premature optimization. If you are writing a front-end for a web service, your performance is not going to be significantly affected by ...


48

Calling a class method with some class variables is not necessarily bad. But doing so from outside the class is a very bad idea and suggests a fundamental flaw in your OO design, namely the absence of proper encapsulation: Any code using your class would need to know that len is the length of the array, and use it consistently. This goes against the ...


44

The word "lambda" or "lambda expressions" most often refers to anonymous functions. So in that sense a lambda is a kind of function, but not every function is a lambda (i.e. named functions aren't usually referred to as lambdas). Depending on the language, anonymous functions are often implemented differently than named functions (particularly in languages ...


41

To quote a conversation I often have with my kids: me: Hey kid! Go find me some batteries kid: But where are they? me: That's why I told you to go find them. If I knew where they were, I would have told you to go get them. Or you could ask your mother. The same idea holds: use "get" for a method which returns a cheaply available piece of ...


40

No, this is perfectly fine. It merely means that the API is over-engineered with regards to your current application. But that doesn't prove that there will never a use case in which the data source and the measurer are different. The point of an API is to offer the application programmer possibilities, not all of which will be used. You should not ...


39

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 ...


39

Short answer: Declaring a method or field "public" translates to a promise: Dear colleages, I invite you to use this method or field wherever you find it appropriate. I have documented everything you need to know about its usage, and as long as you don't violate this documentation, I take responsibility for every bug in this context. ...


36

There is no rule. It's entirely up to how you want to make your API "feel." Personally, in a music player, I think a transition from the state Stopped to Stopped by means of the method Stop() is a perfectly valid state transition. It's not very meaningful, but it is valid. With this in mind, throwing an exception would seem pedantic and unfair. It would ...


34

There isn't any. It is what most people do, so it has become the standard because that is what everyone does. A lot of literature follows this convention so people picked up the habit. The convention isn't as important as the consistency across the code. As long as everything is named in a consistent manner so that I can tell what things are from looking ...


33

I would say it's not only acceptable but encouraged especially if you plan to allow extensions. In order to support extensions to the class in C#, you would need to flag the method as virtual per the comments below. You might want to document this, however, so that someone isn't surprised when overriding ReverseData() changes the way ScheduleTransmission() ...


33

There are may things with the class that I would do differently, but to answer the direct question, my answer would be yes, it is a bad idea My main reason for this is that you have no control over what is passed to the add function. Sure you hope it is one of the member arrays, but what happens if someone passes in a different array that has a smaller ...


32

The core thing here: "brain capacity". You see, one of the main functions of code is ... to be read. And code can be easy to read and understand; or hard. And having a high CC simply implies a lot of "levels" within one method. And that implies: you, as a human reader will have a hard time understanding that method. When you read source code, your brain ...


31

According to MSDN article there are some definition differences what is called parameter and what is called argument: Parameter: A parameter represents a value that the procedure expects you to pass when you call it. The procedure's declaration defines its parameters. Argument: An argument represents the value you pass to a procedure parameter when ...


31

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 ...


29

For example, imagine an initialisation method split into a series of small ones: in the context of method itself, you clearly know that object's state is still invalid, but in an ordinary private method you probably go from assumption that object is already initialised and is in a valid state. The only solution I've seen for this is... Your concern is well-...


28

Long methods are always bad, but are occasionally better than the alternatives.


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