101–105 of 105 posts
_3 = 1;
x3 = 1; // x is not multiply
Many years ago in an age of klocs and flowcharts, at a large three-letter computer company, there were iron-clad coding rules that must be obeyed, no questions allowed. In general you could see their reasoning, but such bureaucratic reasoning doesn't pay off. One example of this was that all numeric values used in a program must be factored out as symbolic constants. The reason for doing this is obvious, but it faile…
An application I touched a few weeks ago has a DB column named 'type' with values 1,2,3. So on to the source code we go: enum RecordType {TypeOne(1),TypeTwo(2),TypeThree(3); RecordType(int dbValue) ...} As it happens, I know an end user of this particular beast, so I show her some record IDs of each type and ask in what way they differ. She looks a few seconds, then says: 'This is clearly a type one record, the next…
https://en.wikipedia.org/wiki/Type_1
https://en.wikipedia.org/wiki/Type_2
https://en.wikipedia.org/wiki/Type_III
https://en.wikipedia.org/wiki/Class_1
https://en.wikipedia.org/wiki/Class_2
https://en.wikipedia.org/wiki/Class_3
etc.
Many years ago in an age of klocs and flowcharts, at a large three-letter computer company, there were iron-clad coding rules that must be obeyed, no questions allowed. In general you could see their reasoning, but such bureaucratic reasoning doesn't pay off. One example of this was that all numeric values used in a program must be factored out as symbolic constants. The reason for doing this is obvious, but it faile…
An application I touched a few weeks ago has a DB column named 'type' with values 1,2,3. So on to the source code we go: enum RecordType {TypeOne(1),TypeTwo(2),TypeThree(3); RecordType(int dbValue) ...} As it happens, I know an end user of this particular beast, so I show her some record IDs of each type and ask in what way they differ. She looks a few seconds, then says: 'This is clearly a type one record, the next…
This was pretty common on mainframes, before db2 and other SQL databases
Earlier quoted context omitted.
An application I touched a few weeks ago has a DB column named 'type' with values 1,2,3. So on to the source code we go: enum RecordType {TypeOne(1),TypeTwo(2),TypeThree(3); RecordType(int dbValue) ...} As it happens, I know an end user of this particular beast, so I show her some record IDs of each type and ask in what way they differ. She looks a few seconds, then says: 'This is clearly a type one record, the next…
This part looks like those people formed a neural network. They are able to learn to act quasi-intelligently, but when you peek inside, the internal model is just a bunch of numbers. Edit: scratch that neural network. They just made one neuron so far.
Earlier quoted context omitted.
#define zero 0 is just bad programming, barring some philosophical code which cares about "zero-ness". Names need to reflect what they represent , not their precise values. Are we looking up the first index? Then how about #define first_index 0 ? Are we summing up values which are coerced to zero when empty? Then how about #define empty_value_integer 0 or #define additive_identity 0 ? Yes, that means there might be m…
>barring some philosophical code which cares about "zero-ness" But that is the intrinsic meaning OP was talking about. Plenty of mathmatics deals with 0 or 1 as important constants. If you have a function that mods by a parameter, you need error handling for zero. Calling it value_that_causes_undefined_behaviour isn't going to improve code clarity. Beyond that; for (i = 0; i , or some variation thereof, is very idiom…