Tag Info

Hot answers tagged

208

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 ...


155

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


85

Get to know your domain Every application is meant to solve a certain issue. This issue belongs to a domain, be it finance, transportation, human resources,... When your users talk about the application, they talk in terms of that domain. So when you think about your application, try to think in terms of that domain using the wording your users also use. ...


83

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


74

I don't think it's the use of abstractions per se that's objectionable. There are two other possible explanations. One is that abstractions are all leaky at one time or another. If you give the impression, correct or not, that you don't understand the underlying fundamentals, that might reflect poorly in an interview. The other possible explanation is ...


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 ...


39

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 ...


32

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, ...


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.


30

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

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 ...


29

Some .NET programmers, particularly those coming from either a classic VB/ASP or a C++ background, don't like new stuff like LINQ, MVC and Entity Framework. Based on what I've observed, the ex-VB'ers in this group are likely to still be using a data access layers and other code originally written 10+ years ago. They'll also use old buzzwords like "n-tier" ...


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 ...


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.”


24

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.


21

In the simplest of terms, you're mentor is asking you to discuss the WHAT of a project, rather than the HOW. WHAT focuses not on the composition of the project, but rather what it allows a human to do (some call this an object's affordance). HOW is the underlying tools used to provide this ability. Here are a few examples. Google WHAT: A search engine that ...


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

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 ...


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 ...


20

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 ...


19

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 ...


19

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.


19

Very broad question, but my quick tips would be: Use a writing pad and a pen for designing your solution. Or a whiteboard. But not Notepad, the app. Seriously - just leave the keyboard. This by itself puts you into a different mindset already, and this different mindset is what you need. Our brains are wired to think in a certain way as long as our palms ...


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

The basic data is structured the same in pretty much any paradigm. You're going to have a Student, a Course, etc. whether it's an object, a struct, a record, or whatever. The difference with OOP isn't how the data is structured, it's how the functions are structured. I actually find functional programs much more closely match how I think about a problem. ...


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 ...



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