New answers tagged

6

In software engineering, few insights are gained through science. Instead, experience and completely unfounded beliefs shape our decisions. This is partly due to the young age of our field (software engineering as a field emerged in the late 60s), but mostly due to the fact that human psychology can be quite difficult to measure. Many people have tried to ...


2

I would consider this not just bad practise but thwarting the principles of OOP because a super call is a different form of call: it is a direct call that bypasses the virtual dispatch mechanism (this is how infinite recursion is avoided when you are trying to call up the class hierarchy from an override). When you switch methods, e.g. from someMethod to ...


0

Explicitly calling super.someMethod() may confuse a reader who is expecting to see that in the context of disambiguating a call. From the Oracle docs on super: [...] you can invoke the overridden method through the use of the keyword super. It doesn't look like it should typically be used for clarity of where the method lives.


0

When coding software, should the architecture always be best practices or practical practices in regards to the application being built? In Theory, yes. In the Real World, [still] yes, as long as you can afford to do so. Which, of course, means, "No". Time and money pressures will always try to push you down the road of a "quick and dirty" solution, ...


0

In my experience there is only one best practice that I consider to be mandatory: Keep It Simple, Stupid (KISS) In other words: Whatever tools, APIs, architectures, etc you choose - if you keep it simple, it's more likely to be easy to work on the future, have less bugs, be fast, memory efficient and everything else you might desire. All those other ...


1

I'll try to view from a different perspective. Today's modern frameworks make it very easy to setup a basic project with mvc, dependency injection, layered architecture etc. (spring boot lover here). I'd say start with a generated base and use the tools provided for you, until you bump into something that requires a handmade solution. Then you may cut ...


2

No. Best practices are things that are generally considered to be the best thing to do 99% of the time, but that doesn't mean they always apply to every situation. As a developer your job is to know and use those best practices, but also know when it's safe to cast them aside. This isn't supposed to be self-promotion, but I recently wrote a blog post ...


2

I assume by "best practices" you mean some list of rules that someone wrote in a book. For of course if you mean the phrase literally, then of course you should always write the best code you can. Need I point out that there is not a single, universally-accepted set of "best practices"? For any rule promoted by one expert, you can almost always find another ...


1

Some things are important, some aren't. You should tailor your choice of language and style to the problem at hand. For instance, a "Best Practice" for exception handling might be to always catch exceptions and log them, but when creating a unit test the best practice is often to let them throw out so the unit testing framework can report them correctly. ...


1

By best practices, I'm assuming you mean "informal rules that the software development community has learned over time which can help improve the quality of software" and not some sort of literal best way of doing a specific task. Yes, until you have a reason not to. It should be a good reason that you've given serious consideration and applied to the ...


0

The best "Best Practices" always contain a section that you should use your intelligence and experience to identify when the items in the manual are inappropriate. They may also contain a section on reviewing, approving, and documenting such exceptions and making them part of the "best" practices.


11

The best practice is the one that most effectively fulfills your software's functional and non-functional requirements for features, maintainability, performance, etc. If that practice happens to align with some "industry standard," that's awesome. But if it doesn't, pragmatism wins. Where I currently work, we're building a new web UI for our product from ...


40

Should coding best practices always be used Always? No, that's silly. Best practices are guidelines. For most people, for most situations, if implemented with some finesse, they will yield the best results. They're where you start when considering solutions. But there will be places where best practices can and should be ignored, because there are better ...


30

Yes. That is self-evident. Why would you not do what is best? That's not the issue though. The hard part is finding out what IS the best practice, because in order to answer that you need to know exactly what requirements you have and how the project is likely to evolve over the years, and that is fiendishly hard. One good rule of thumb however: It is NOT ...


2

According to GNOME commit style guideline, the first line should of the commit message be a short description (ideally no more than 72 characters) and it should not end up with a full stop. In summary: First line (the brief description) must only be one sentence and should start with a capital letter unless it starts with a lowercase symbol or ...


-1

I think it is better to defer this kind of decision-making to the framework designer, and use one JavaScript framework that encapsulates this kind of complexity. Nowadays we have AngularJS, JQuery, ReactJS, and so on, doing things without a framework would get you this kind of difficulties.


4

If the e2 catch is, as you say, only to catch errors in initializing x and doing otherStuff you could extract it to a seperate method. This also seperates the logic nicely and allows you to potentially give a meaningful name to otherStuff. public X Foo() { try{ X x = blah; otherStuff; return x; } catch(Exceptions2 e2){ ...


3

I have a few observations on your question: In the example you provided you don't need exceptions at all. You would only need to check the string y, log any error, and exit the loop. Nothing is exceptional about y being invalid and needing to be logged. The fact you are using exceptions in this case is indication of code smell. Multi-Catch exceptions are ...


7

Unless you intend to process the entire inner loop whether an exception occurs or not, your code is essentially equivalent to try{ X x = blah; otherStuff; for (...){ f(x) } } catch(Exceptions1 e1){ ... } catch(Exceptions2 e2){ ... } which does not require nesting. If you still need the inner exception handling, refactor ...


0

Changing them becomes a major hurdle, and people will adhere safely to the letter of the law rather than engage brains and do the right thing. There will come a day when part of the standard is unhelpful, and makes the code worse. Some people will adhere to the standard, because it's written down and they're safe, and because rules are there to be followed. ...


0

I think many posts here are confusing coding standard with style guide. Making sure that modules developed by different teams have the same compiler options and ABI is a different kind of thing from how many spaces are indented. Things like the proper way to structure #include files and not polluting the global namespace in a header file should be ...



Top 50 recent answers are included