Elegant is usually the opposite of maintainable. Reading elegant code is like reading a book of riddles (which is one of the reasons we enjoy it.)

▲ n4r9 10 days ago | parent | next [-]

True, but we shouldn't understate how beneficial elegant solutions can be in the appropriate setting. Sometimes you read code that gives you a new and memorable way to think about a certain kind of problem.

▲ pessimizer 10 days ago | parent [-]

I agree we like it. I don't want to have to review it. I'd rather review code where the bugs stick out like blinking yellow lights, even if it runs 10% slower (or 1000% slower, if I'm only running it once.)

	▲	n4r9 8 days ago \| parent [-]
		I guess it depends what mean by "elegant". For me, an elegant solution makes it obvious that certain classes of bugs will not be present. For example, suppose you have an application that connects to 17 queues and processes a different type of request from each. You could do this in lots of lines as follows: `var processors = new Processor[18]; processors[0] = client.CreateProcessor("FooQueue") { Handler = GetHandler("FooRequest") }; log.Write("Connected to Foo Queue"); ... processors[17] = client.CreateProcessor("BarQueue") { Handler = GetHandler("BarRequest") }; log.Write("Connected to Bar Queue");` Or you could do this: `var queues = new List<string> { "Foo", ... , "Bar" }; var processors = queues.Select(q => client.CreateProcessor(q + "Queue") { Handler = GetHandler(q + "Request") };` The former - despite being "warts and all" - is more prone to bugs getting missed in development and review.

▲ packetlost 10 days ago | parent | prev [-]

Your definition of elegant is definitely different from mine lol

	▲	Izkata 10 days ago \| parent [-]
		Yeah, I'd define elegant as something like "unexpectedly simple and easy to understand", relative to the simple approach to the problem at hand.