Stack Exchange Network

Stack Exchange network consists of 175 Q&A communities including Stack Overflow, the largest, most trusted online community for developers to learn, share their knowledge, and build their careers.

Visit Stack Exchange

New answers tagged

3

First, in the shown case, it makes no sense to introduce an explaining variable since using the function directly is equally readable, so you could write: function hello(suffix) { if (isSuffixString(suffix)) { return `Hello ${suffix}` } else { return 'Invalid entry' } } However, if you need the result of a function call more than once, it ...


0

This is probably a matter of personal tastes. I have several verb prefixes that I use for functions. In your case I'd use check. For me, a function like check...() must always return true or false (or raise an exception), and must be idempotent. So I would write, const checkedIsSuffixString = checkIsSuffixString(suffix) if (checkedIsSuffixString) { // ...


1

I don't think that there's a hard rule here, you need to ultimately use your own judgement. The context of the organization will play a huge role in the decision. Consider that my background is in highly regulated industries. Making changes beyond the scope of the defined issue has huge impacts to traceability that is required for compliance reasons. So ...


1

Every impediment to opportunistic refactoring that is introduced is going to reduce the amount of refactoring actually done. This sort of refactoring is most likely going to be in the same files and likely the same functions of any functional changes, trying to segregate it to multiple changesets isn't going to happen often in practice. If you notice that ...


1

I see this question as addressing an informal vs formal issue. I've never believed in formalism for it's own sake so long as you're responsible. To be opportunistic you have to be exploiting an opportunity to pay down technical debt for a cheaper expense than if you'd filled a full-blow, self-standing, ticket against this issue. That ticket would require ...


1

If you stumble on an area that has technical debt, the first thing to do is add something to your backlog characterizing the problem. This is not an area you are actively developing on. It's also work that needs to be tracked and accounted for. A well functioning team will set aside a certain amount of capacity to pay down technical debt along with the ...


1

This is about refactoring, which means modifying code without changing its meaning. You can refactor from the left to the right, or from the right to the left, whichever you prefer. Actually we have two refactorings here: replacing an expression with a function, and replacing a variable storing the expression with multiple evaluations (of the expression or ...


3

I concur with candied_orange's answer but I would caution that the specific refactoring mentioned here could cause subtle hard-to-detect bugs and/or instabilities. The given refactoring can only be known to be equivalent if and only if it's guaranteed that the values of quantity and itemPrice will not change during the execution of the method. If there's ...


2

The main reason I'd use the right-side code is that it allows for unit-testing basePrice(). Is that something worth unit-testing? Maybe; depends a lot on the specific details.


2

You can refactor your method to return a Response object and use a custom deconstructor. Like this: public class Response<T>{ public T Value{ get; set;} public HttpStatusCode Status{ get; set;} public ErrorResponse Error{ get; set;} public void Deconstruct(out T value, out HttpStatusCode status){ value = Value; status = ...


1

What is a useful/recommended approach to addressing this situation? That depends on how set in stone the statement, "20-20 hindsight is a wonderful thing but unfortunately doesn't provide a simple way forward" is. If you are using semantic versioning and you have a good set of automated tests covering your back when making changes, then it may well be a way ...


6

To me, using the local variable to capture a query result (query of the object state) says something significant: that I'm only doing one query of these field values (to compute one value), and, my logic expects to work with that one value.  This I find to be clear and simple. Whereas repeating the field accesses — whether directly or by method ...


19

A refactoring is not a best practice. A refactoring is a way to change code without changing externally visible behavior. A single well written unit test should be able to pass both the left code and the right code without being touched. You're reading this post as if the code on the left is always a problem. It's not. Sometimes the code on the right is ...


Top 50 recent answers are included