3 ms·

An example that superficially looks like "cut and paste" programming occurs is actually implementing a new derived class. In the C++ case, you could: 1. Type o

by Gupie 11y ago

An example that superficially looks like "cut and paste" programming occurs is actually implementing a new derived class. In the C++ case, you could: 1. Type out the new .h and cpp files from scratch. 2. Copy/rename the base class .h file, remove all non virtual functions and other text not needed for a derived class, copy/rename this new header creating a .cpp file, convert method declarations to definitions, and add method implementations. 3. Copy/renamed the .h and .cpp files for an existing derived class and replace the existing method implementations. Option 3 is a reasonable choice and is an example of what article article discusses.

scott_s 11y ago
Option 3 is a reasonable choice, but I don't think it's an example of what the article discusses. The example you provided is a good one, because it's an instance where you can't write abstractions to help you in the language you're using. Defining new classes, their interfaces and members is part of the necessary scaffolding when writing in C++. (Let's pretend it's not possible to do this with the C preprocessor.) But the first example in the article does not sound like your example. Rather, it sounds closer to im3w1l's example, where the programmer copied code for some particular functionality, not for scaffolding.
- Gupie 11y ago
  I don't see im3w1l's example as copying code for some particular functionality, it's copying boilerplate code needed to use a particular library. First the library is initialised, passing in a number of parameters to an initialisation function. If the values of these parameters are the same in multiple instances in the same codebase then that is violating DRY, but if the parameters differ it's just the scaffolding that you are reusing.
  - scott_s 11y ago
    The difference, to me, is that it's scaffolding code that can be abstracted. You can't abstract writing a class - it's a primary activity in the language. Only macros can help you there - either the broken ones provided by the C preprocessor, or real ones provided by languages like Racket or Rust. But boilerplate code that interacts with an external library is not a primary activity in the language. You can hide it behind a class or a family of functions.

by Gupie 11y ago

scott_s 11y ago

Option 3 is a reasonable choice, but I don't think it's an example of what the article discusses. The example you provided is a good one, because it's an instance where you can't write abstractions to help you in the language you're using. Defining new classes, their interfaces and members is part of the necessary scaffolding when writing in C++. (Let's pretend it's not possible to do this with the C preprocessor.) But the first example in the article does not sound like your example. Rather, it sounds closer to im3w1l's example, where the programmer copied code for some particular functionality, not for scaffolding.

Gupie 11y ago
I don't see im3w1l's example as copying code for some particular functionality, it's copying boilerplate code needed to use a particular library. First the library is initialised, passing in a number of parameters to an initialisation function. If the values of these parameters are the same in multiple instances in the same codebase then that is violating DRY, but if the parameters differ it's just the scaffolding that you are reusing.
- scott_s 11y ago
  The difference, to me, is that it's scaffolding code that can be abstracted. You can't abstract writing a class - it's a primary activity in the language. Only macros can help you there - either the broken ones provided by the C preprocessor, or real ones provided by languages like Racket or Rust. But boilerplate code that interacts with an external library is not a primary activity in the language. You can hide it behind a class or a family of functions.