Tag Info

New answers tagged

0

Although the question has already useful answers, one detail seems to fall too short. Most programmers are at first a bit confused with the using keyword and the descriptions of namespace usage, even if they try to learn it by looking up the reference, because declaration and directive reads somewhat equivalent, both are relatively abstract long words ...


1

As I see it, the importance of source code formatting is secure and fast navigation. That's why line comments should safely been skipped, of course without reading them. As to distinguish comments (//) and documentation (///) from so-called "commented-out blocks" in committed source code, I decided to use two special line comment styles. This was several ...


4

While I don't have an authoritative answer, in my experience it would depend on the situation. Usually, the redundancy is unneeded. The main point here is readability, and shorter is typically better. And, as you've already mentioned in the question, there's no functional difference, so write whichever one better fits the logic of the model and will make it ...


0

The convention I've seen codebases adhere to is to prefer a style that is clear from the syntax. If the function changes value, prefer pass by pointer void predictPrice(Item * const item); This style results in: Calling it you see: predictPrice(&my_item); and you know it will be modified, by your adherence to style. Otherwise prefer pass by ...


0

Syntax is different between different languages, and it is meaningless to show a piece of code that is not specific to a language because it means completely different things in different languages. In Java, Item is a reference type -- it is the type of pointers to objects that are instances of Item. In C++, this type is written as Item * (syntax for the ...


0

While I have not a strong preference, I would vote that returning the object leads to better flexibility for an API. Note that it has sense only while the method has freedom to return other object. If your javadoc says @returns the same value of parameter a then it is useless. But if your javadoc says @return an instance that holds the same data than ...


5

Within an object oriented design paradigm, things shouldn't be modifying objects outside of the object itself. Any changes to the state of an object should be done through methods on the object. Thus, void predictPrice(Item item) as a member function of some other class is wrong. Could have been acceptable in the days of C, but for Java and C++, the ...


9

This really is a matter of opinion, but for what it's worth, I find it misleading to return the modified item if the item is modified in place. Separately, if predictPrice is going to modify the item, it should have a name that indicates it's going to do that (like setPredictPrice or some such). I would prefer (in order) That predictPrice was a method of ...


6

Note: don't use print for logging purposes. Using print may work for small applications, but when the application starts increasing, moving to the actual logging would quickly become unavoidable. To avoid future maintenance cost, consider using logging from the beginning. Make sure you use existent predefined logging frameworks and don't reinvent the wheel. ...


2

There is better ways to enable your users to follow the scripts actions. One way is to return an object that describes what steps happend, what the result is and how long the steps took. If it breaks, you should throw an exception which includes additional information. Another way to do this is using AOP features. These are however not builtin python and ...


2

Keep in mind that typically the solution is not always collapsing some of the arguments into a distinct data structure. Most of the times you should split the functions into multiple ones because probably it's the function itself that does multiple things. I remember Uncle Bob in Clean Code saying there should be at most 2 and only in special cases 3 ...


7

How many functions do you have that uses those parameters? If you have 4 functions that all take the same 12 parameters, it's a sign that you probably should bundle those into a cohesive set. If you have 4 functions that use say... 8 of the parameters, then maybe those 8 should be bundled up. But this is rather missing a little bit of the point. Bundling ...


9

The "premature optimisation is the root of all evil" thingy is nice and cute, but it is often misinterpreted and should not be used as an excuse to write poor code: if you can easily write code that obviously performs better, you should (for example by choosing the right data structure or avoiding to loop twice when one loop can do the job). In the simple ...


9

Premature Optimization is the root of all evil. As Donald Knuth said, Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small ...


8

If the code change results in a... measurable performance improvement that satisfies a non-functional software requirement, and you cannot satisfy the requirement using simpler code ...then make the code change. Otherwise, you're almost always better off writing code that is easier to understand and more maintainable.


0

To be perfectly honest, I don't give a hoot about LOC measurement. Sure, it is nice for a function or procedure to be as short as possible, but I take readable code over short any time of day.



Top 50 recent answers are included