Id Software Programming Principles

Post by [deleted] » Tue, Feb 28, 2017, 2:49 AM UTC

charleslmunger wrote: post #74

alkonaut wrote: post #73

Earlier quoted context omitted.

There is - but there is no good reason to not have good naming plus also a simple wrapper to do the most common cases. That the IO framework is very general is good, but that you need tons of boilerplate for a common scenario is bad. C# var txt = File.ReadAllText("file.txt"); This is exactly the abstraction you want if you want to read a (whole) text file. The point of abstractions is to pick the right one. For IO it…

Like this? https://docs.oracle.com/javase/7/docs/api/java/nio/file/File...

Post by JustSomeNobody » Tue, Feb 28, 2017, 3:15 AM UTC

crdoconnor wrote: post #60

Hansi wrote: post #12

> "No prototypes. Just make the game. Polish as you go. Don’t depend on polish happening later. Always maintain constantly shippable code." I disagree with this so much, prototypes and proof of concepts teach you so much but usually they are crap you will always write it better a second time. Throw away the prototype and re-write it as a much better implementation.

>you will always write it better a second time. No. You won't: https://en.wikipedia.org/wiki/Second-system_effect