Tag Info

Hot answers tagged

209

Simple solutions are better for long-term maintenance. And it's not always just about language familiarity. A complex line (or lines) takes time to figure out even if you're an expert in the given language. You open up a file and start reading: "ok, simple, simple, got it, yep, WTF?!" Your brain comes to a screeching halt and you now have to stop and ...


149

Basically we want things to behave sensibly. Consider the following problem: I am given a group of rectangles and I want to increase their area by 10%. So what I do is I set the length of the rectangle to 1.1 times what it was before. public void IncreaseRectangleSizeByTenPercent(IEnumerable<Rectangle> rectangles) { foreach(var rectangle in ...


102

KISS Principle Keep it simple, stupid. Clever solutions are great, but often the simplest straight forward solution is best. “Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.” Brian Kernighan


83

Fools ignore complexity; pragmatists suffer it; experts avoid it; geniuses remove it. -- Alan Perlis


59

The very first words of TC++PL4: All problems in computer science can be solved by another level of indirection, except for the problem of too many layers of indirection. – David J. Wheeler (David Wheeler was my thesis advisor. The quote without the important last line is sometimes called "The first law of Computer Science.")


43

Use a dispatch table. This is a table containing pairs ("message part", pointer-to-function). The dispatcher then will look like this (in pseudo code): for each (row in dispatchTable) { if(message.toLowerCase().startsWith(row.messagePart)) { row.theFunction(message); break; } } (the equalsIgnoreCase can be handled as a ...


37

The reason for hiding the details isn't to keep the details hidden; it's to make it possible to modify the implementation without breaking dependent code. Imagine that you've got a list of objects, and each object has a Name property and other data. And a lot of times, you need to find an item in the list whose Name matches a certain string. The obvious ...


31

I think you have some misconceptions about the history of computing. The first abstraction (in 1936) was, in fact, Alonzo Church's Lambda Calculus, which is the foundation for the concept of high-order functions and all of the functional languages that followed. It directly inspired Lisp (the second oldest high-level programming language, created in 1959), ...


30

The best solution is not always the most clever solution. Sometimes simple solutions are equally good. In Software you always need to think in terms of maintainability. If a piece of code is too clever for someone who is going to maintain it, I would say that cleverness is not worth it.


29

The answer to "Can you define what a programming abstraction is more or less mathematically?" is "no." Abstraction is not a mathematical concept. It would be like asking someone to explain the color of a lemon mathematically. If you want a good definition though: abstraction is the process of moving from a specific idea to a more general one. For example, ...


29

It seems to me that you misunderstand abstractions and code reuse. The whole software development industry is built on abstractions. Just because not using them, i.e. avoiding using frameworks, libraries and in general code which is not written in-house, would increase the cost you need to produce a piece of software by hundred, thousand, probably even ...


28

I'd probably do something like this: public interface Command { boolean matches(String message); void execute(String channel, String sender, String login, String hostname, String message); } Then you can have every command implement this interface, and return true when it matches the message. List<Command> activeCommands = new ...


27

Which to listen to and how often? Never abstract until you must. In Java, for example, you must use interfaces. They're an abstraction. In Python you don't have interfaces, you have Duck Typing, and you don't need towering levels of abstraction. So you just don't. What is your strategy for this? Don't abstract until you've written it three ...


26

To quote Brian Kernighan: “Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.”


23

If all your objects are immutable, there is no problem. Every Square is also a Rectangle. All the properties of a Rectangle are also properties of a Square. The problem begins when you add the ability to modify the objects. Or really - when you start passing arguments to the object, not just reading property getters. There are modifications that you can do ...


22

cleverness is a tool; by itself it is not harmful. It only becomes harmful in context where it is not necessary.


20

I categorically disagree with most of the answers. This is my answer: Given two sets G and H, a Galois connection (alpha, beta) can be defined between them, and one can be said to be a concretization of the other; reverse the connection, and one is an abstraction of the other. The functions are a concretization function and an abstraction function. ...


20

Yes, definitely. The thing is, no abstraction is perfect. All of the details of the layer that abstractions sit atop are there for a reason, and it can simplify a lot of things, but if that complexity wasn't necessary at some point, it probably wouldn't be there in the first place. And that means that at some point, every abstraction is going to leak in ...


19

Frameworks can be tricky indeed. Problems can easily arise when a framework is too "opinionated", i.e. when it really prefers one particular style of application and all parts are geared towards supporting this particular style. For instance, if the framework completely abstracts the authentication process of a user by allowing you to just add one ...


18

Ah, YAGNI. The most abused concept of programming. There's a difference between making your code generic and doing extra work. Should you spend extra time to make your code loosely coupled and easily adapted to do other things? Absolutely. Should you spend time implementing unneeded functionality? No. Should you spend time making your code work with ...


18

You write concrete code first. You write abstract code when you must because it simplifies concrete code. It easiest to start with concrete and find the abstractions after studying what's similar and different about the concrete.


18

Why is programming not like this? Why do you think that? Actually, programming is like that. Of course, you can't do that in assembler. Therefore we invented languages that can be more similiar to the human thoughts. Good programmers program alike examples you gave. But it is not as easy. First you have to understand, what the requirement is. This is ...


16

"Clever", when applied to code, is almost always just a euphemism for "needlessly complicated". Reading good, clear, simple code is hard enough. Reading "clever" code is like studying latin poetry all over again. The confusion arises because "clever" as an attribute of a person has a completely different meaning. This case can also be seen as an example of ...


15

Good uses for wrapper functions: Hiding the complexity of a horribly complex or unsafe, low-level API, for example, the Win32 API. However, your wrapper must actually reduce complexity and/or increase safety for the common cases. Making something cross-platform when you are writing a generic library or have a good reason to believe it needs to be ...


15

The keyword for thinking about these things is abstraction. Abstraction just means deliberately ignoring the details of a system so that you can think about it as a single, indivisible component when assembling a larger system out of many subsystems. It is unimaginably powerful - writing a modern application program while considering the details of memory ...


14

Dependency Injection and DDD are two disjoint concepts. Doing Dependency Injection does not require to do DDD nor does DDD require Dependency Injection. A lot of DDD projects fail because they pick the patterns but neglect the process behind DDD. They do not take the time to extract business rules. They do not concentrate on the domain model and on careful ...


14

You are using Java - so make it beautiful ;-) I would probably do this using Annotations: Create a custom Method Annotation @IRCCommand( String command, boolean perfectmatch = false ) Add the Annotation to all relevant Methods in the Class e.g. @IRCCommand( command = ".np", perfectmatch = true ) doNP( ... ) In your constructor use Reflections to ...


13

ADT is to an interface (what it does) what a data structure is to a class (how it does it). A few examples: ADT: List DS: ArrayList, LinkedList... ADT: Map DS: HashMap, TreeMap... I guess you get the point.


13

Sometimes a change is large enough that you have to design a migration path. Even if the start and end points are well designed, you often can't just switch cold turkey. A lot of otherwise good designers fail to design good migration paths. This is why I think every programmer should do a stint writing software for 24/7 production environments. There's ...


12

Yes, every programmer should learn new languages, and particularly languages that uses a different programming paradigm e.g. functional programming or concurrency oriented programming. Even if you will not use the language, you will be a better programmer in the language you use by learning different concepts and see alternative solutions. There is an ...



Only top voted, non community-wiki answers of a minimum length are eligible