3

I've heard some developers say that if a variable is only referenced one place, to just replace the reference to it with the value assigned to it. I've also heard developers say if a function is only called once, to just put its statements in place of the single call to it.

The reasoning typically given is that when reading the code you don't have to "jump all over" just to find out what the code is doing.

What patterns or practices would such inlining either adhere to or violate? What benefits are there to inline or to avoid it?

Things that come to mind:

  • similar to the Single Responsibility Principle, writing functions that don't try to do "too many things" (hence, easier to write, test, read/maintain)
  • optimize for the reader of the code, not the writer
  • added overhead of function calls and memory allocation (perhaps only relevant in older languages?)

I think this is distinct from some other questions in the neighborhood that didn't seem to ask/answer the same question.

jinglesthula
  • 305
  • 1
  • 8
  • Not really a duplicate, but the answers [to this question](https://softwareengineering.stackexchange.com/questions/335783/my-boss-asks-me-to-stop-writing-small-functions-and-do-everything-in-the-same-lo/335792#335792) cover this quite well. (Warning, I'm biased here, as my answer is the top voted one ;) ) – David Arno May 16 '18 at 20:08
  • 4
    Or to put it another way, "some developers" spout a lot of nonsense. If you have a method that is hundreds of lines long, you'll still be "jumping all over the place". – David Arno May 16 '18 at 20:10
  • If they don't use a code editor that allows them to navigate caller/callee at the fingertip, then I can understand why they'd say that. – rwong May 16 '18 at 20:56
  • 1
    @rwong, "If they don't use a code editor that allows them to navigate caller/callee at the fingertip...". I've noticed that screws are really hard to drive into wood with a hammer. Cleverly this means that screws are badly designed. Make them easy to drive home with a hammer! If your editor hinders good coding practices, don't blame it on the code. Switch to using the right tool. – David Arno May 17 '18 at 07:15
  • If you keep de referencing code like that, you'll end up with few, very big and hard to navigate source files. – S.D. May 17 '18 at 08:19
  • @DavidArno Thanks. When I was writing that comment, I actually thought about using the word "macho", but I deleted it because I didn't want my answer to refer to a stereotype. But maybe the stereotype is correct and I was wrong not to use it. – rwong May 18 '18 at 01:57
  • @S.D. Though I wonder if you won't need to try to navigate them. Hopefully you'd be working in functions that are easier to read because the implementation is abstracted and what's left is semantics. Or you're working in one of the focused functions referenced and it's brief and easy to read. Navigation itself should be a non-issue in modern editors, imo. – jinglesthula May 18 '18 at 19:11

2 Answers2

11

You only need one reason to create a variable or a function: to improve clarity.

Variables at the top of a class or module provide a single point of reference and give something a meaningful name.

The primary purpose of creating a method is not to consolidate repetitive code; it is to encapsulate functionality and give it a meaningful name. Methods are the great conqueror of complexity; once you write and test a method, you no longer have to reason about what's inside it.

You don't have to "jump around" in any significant sense; most modern IDEs will tell you what that variable or method reference refers to if you simply hover the mouse over it.

Single Responsibility Principle is a concept that applies to classes, not methods. Overhead is inconsequential, in most cases.

Robert Harvey
  • 198,589
  • 55
  • 464
  • 673
  • 1
    I do wonder about SRP applying only to classes. Wikipedia says "every module or class", and Crockford says in The Good Parts (chapter 4 intro) that "functions are the fundamental modular unit of JavaScript. Of course, this was before ES2015 added actual modules. This question has some good discussion on it https://softwareengineering.stackexchange.com/q/275646/115964. For clarity, though, I think I will edit the question a bit. – jinglesthula May 16 '18 at 20:52
  • This. I think a big part of the confusion comes from so many beginner-level classes and language documents that continually refer to method reuse, which is completely backwards from why you actually segment your program (that is - a large portion of many programs will be single-use paths). – Clockwork-Muse May 17 '18 at 15:17
  • @Clockwork-Muse: I teach an Introduction to C course at the local college, and functional composition is the very first thing I teach, in the first day of class (you can teach it using simple math functions without knowing the C language). – Robert Harvey May 17 '18 at 15:22
  • @RobertHarvey To expand on the idea of improving clarity, perhaps another way of saying it is "if the implementation is getting in the way of reading part of your code, abstract a logically cohesive part". – jinglesthula May 18 '18 at 19:14
3

I can only think in two times when you need to check what a method does:

  • Method name is not self-explanatory. You have to give meaningful names to your methods, variables, classes... It wouldn't help the reader if you refactor some lines out into a method called a(): it did encapsulate the implementation, but I have no clue about what that method does. The problem there is the naming, not having a lot of methods.

  • You need to fix something inside the logic. Having to fix something, I prefer it to be in a small context with very few possible side effects than in a long method with a lot of logic going on and spread along. Besides, a good method name will help me to know where is the bug or the change in the business logic.

Apart from that, variable declarations/instantiations should be as near as possible to the place where they are used. This way, I can infer why they are needed. But I can understand that might depend on the language and the context.

A Bravo Dev
  • 254
  • 1
  • 4