|
There's no need to refactor Q_rsqrt at all. The only things missing are comments that actually explain how it works. "Self-documenting code" doesn't mean that your code should literally have the explanations of how it works in the names of the variables and functions.
|
# ? Nov 23, 2012 22:41 |
|
|
# ? Jun 5, 2024 06:32 |
|
Ithaqua posted:That seems like a great example of code that can easily be refactored to be a lot more descriptive about what the gently caress it's actually doing. I'd like to see how you can refactor that code to be more descriptive about how it works, given that there are entire papers written about the technique. Sure, better comments make a world of difference, but attempting to make this code self-documenting is probably a serious waste of time.
|
# ? Nov 23, 2012 22:42 |
|
Ithaqua posted:That seems like a great example of code that can easily be refactored to be a lot more descriptive about what the gently caress it's actually doing. I wasn't very clear in the post, that is an example of the proper time to use stupid assembly tricks, xor swap isn't. And I was being very sarcastic about the comments. As for what it is, thats the classic abusing IEEE 754 fast inverse square root. Its using one iteration of newton's method to approximate the inverse square root, which is used in a ton of lighting calculations. These days you'd "refactor" it to one SSE instruction, or more likely, a shader program. Didn't have either of those things in 1999.
|
# ? Nov 23, 2012 22:43 |
|
Yeah, that code is clearly doing crazy floating point stuff, and the best thing to do is toss your hands up and let it do its own thing (or check that it's actually faster than 1/sqrt(x) on the hardware and if not change it).
|
# ? Nov 23, 2012 23:05 |
|
Cocoa Crispies posted:If your functions are taller than about ten (twenty is pushing it) lines that's the problem. I can't recall where I read it but the adage I found to be more useful is the number of variables in a function, rather than the length. (ps, bikeshed should be blue, etc)
|
# ? Nov 23, 2012 23:08 |
|
tef posted:I can't recall where I read it but the adage I found to be more useful is the number of variables in a function, rather than the length. Yes, but how many variables?
|
# ? Nov 23, 2012 23:18 |
|
tef posted:I can't recall where I read it but the adage I found to be more useful is the number of variables in a function, rather than the length. Another red flag for me is seeing a a lot of repetitive code that could be easily factored away in a generic function or a shitload of functions that are always called in succession. (ps, there are no programming discussions that don't end up in a bikeshed though.)
|
# ? Nov 23, 2012 23:18 |
|
Zombywuf posted:Yes, but how many variables? Seven.
|
# ? Nov 24, 2012 00:00 |
|
The developer I replaced prefaced every single one of his variable names with "the." Sometimes he used semantic names ("theYear"), sometimes he used vague and unhelpful ones ("theResult"), sometimes he just concatenated it with the type name ("theJSONObject"). It's utterly maddening.
|
# ? Nov 24, 2012 01:43 |
HORATIO HORNBLOWER posted:The developer I replaced prefaced every single one of his variable names with "the." Sometimes he used semantic names ("theYear"), sometimes he used vague and unhelpful ones ("theResult"), sometimes he just concatenated it with the type name ("theJSONObject"). It's utterly maddening. Let's call it Long Reverse-Hungarian Notation.
|
|
# ? Nov 24, 2012 02:08 |
|
HORATIO HORNBLOWER posted:The developer I replaced prefaced every single one of his variable names with "the." Sometimes he used semantic names ("theYear"), sometimes he used vague and unhelpful ones ("theResult"), sometimes he just concatenated it with the type name ("theJSONObject"). It's utterly maddening. I've had to maintain some code that has variable names like this. Boggles my damned mind with regards to why someone would think this was wise.
|
# ? Nov 24, 2012 05:06 |
|
Tab completion is of the devil and must be opposed on all fronts.
|
# ? Nov 24, 2012 05:09 |
|
Volte posted:There's no need to refactor Q_rsqrt at all. The only things missing are comments that actually explain how it works. "Self-documenting code" doesn't mean that your code should literally have the explanations of how it works in the names of the variables and functions. I generally only trust the code with showing me what it's doing, and the comments to tell me why it needs to be done. PS: Can we get back to the horrors or do we have another couple pages of nitpicking to get through
|
# ? Nov 24, 2012 06:08 |
|
Aionic Duck posted:I've had to maintain some code that has variable names like this. Boggles my damned mind with regards to why someone would think this was wise. I'm pretty sure it's from Borland's books. I remember something very similar from both Turbo Pascal and Turbo C's examples. Delphi is probably similar.
|
# ? Nov 24, 2012 16:10 |
|
trex eaterofcadrs posted:I'm pretty sure it's from Borland's books. I remember something very similar from both Turbo Pascal and Turbo C's examples. Delphi is probably similar. Apple uses a similar style in a lot of their code for parameter names, especially in the case of setter methods where you want to name the parameter something that doesn't collide with the instance variable of the same name: code:
|
# ? Nov 24, 2012 16:24 |
|
trex eaterofcadrs posted:I'm pretty sure it's from Borland's books. I remember something very similar from both Turbo Pascal and Turbo C's examples. Delphi is probably similar.
|
# ? Nov 24, 2012 16:26 |
|
KARMA! posted:Another red flag for me is seeing a a lot of repetitive code that could be easily factored away in a generic function or a shitload of functions that are always called in succession. If you ever notice that you are writing the same thing again, write a new function or assign a variable. That said, yaoi prophet posted:Seven.
|
# ? Nov 24, 2012 17:02 |
|
Zombywuf posted:People look at me weird when I say function names should not include the word "and". Sometimes they have the decency to look embarrassed though. I know, whenver I see testAndSet used I always think it's dying to be broken up into two separate functions.
|
# ? Nov 24, 2012 18:14 |
|
Jonnty posted:I know, whenver I see testAndSet used I always think it's dying to be broken up into two separate functions. Amateur. TestAndSet should be three functions.
|
# ? Nov 24, 2012 18:39 |
|
code:
|
# ? Nov 25, 2012 00:05 |
|
You and your tight-coupling.code:
|
# ? Nov 25, 2012 00:48 |
|
PrBacterio posted:Huh? I don't remember anything like that from my DOS Turbo Pascal / Delphi days. The usual naming convention was to prefix type names with a T, and then have variables which have no identity beyond that, e.g. callback parameters, just named after the generic noun, i.e. canvas: TCanvas, and so on. T* was the type, the actual instance was the* for instance variables where only 1 would exist at a time. I had to dig but I did find at least one official borland example for Turbo Vision of all things where they did this: C++ code:
|
# ? Nov 25, 2012 00:48 |
|
trex eaterofcadrs posted:T* was the type, the actual instance was the* for instance variables where only 1 would exist at a time. I had to dig but I did find at least one official borland example for Turbo Vision of all things where they did this:
|
# ? Nov 25, 2012 12:49 |
|
Jonnty posted:I know, whenver I see testAndSet used I always think it's dying to be broken up into two separate functions. I know right, I use low level locking operations all the time in my code.
|
# ? Nov 25, 2012 12:54 |
|
How 2 program computers like a b0ss: Maximum 10 lines in a function Maximum 7 variables in a function Never use "tmp" as a variable name Never use the word "and" in a function name Only have a single point of exit from a function Never use goto Kill yourself Please memorize all of this retarded poo poo it will be in the exam.
|
# ? Nov 25, 2012 14:50 |
|
C coding makes one p. mad.
|
# ? Nov 25, 2012 18:13 |
|
Dicky B posted:How 2 program computers like a b0ss: So longjmp is cool?
|
# ? Nov 25, 2012 21:15 |
|
On a more serious note I have to look at other people's code a lot, and it is difficult. The nature of this difficulty usually has nothing to do with the trivial details of their coding "style" such as the names of temporary variables and the lengths of functions. It is higher up, in the way the program is structured, how things are encapsulated etc. You can throw as many silly blanket rules at that problem as you like and it's not going to help. Of course it's fun to blue bikeshed about this stuff. I'm guilty of it myself.
|
# ? Nov 25, 2012 21:22 |
|
Suspicious Dish posted:I have high hopes for Rust Clay is more promising than Rust imo
|
# ? Nov 25, 2012 22:33 |
|
Dicky B posted:On a more serious note I have to look at other people's code a lot, and it is difficult. The nature of this difficulty usually has nothing to do with the trivial details of their coding "style" such as the names of temporary variables and the lengths of functions. It is higher up, in the way the program is structured, how things are encapsulated etc. It's always a good idea when you're writing code to mimic the conventions of the standard libraries for that language. Whatever your own preferences are. That'll at least make it easier for others to get a grasp on how your thing is structured. For example, when I write Objective-C code, I try to use as many Cocoa conventions and patterns as apply to the project - delegates, notifications, key-value coding/observing, etc.
|
# ? Nov 25, 2012 22:38 |
|
Zombywuf posted:I know right, I use low level locking operations all the time in my code. Here's a reaction to a prior horror which may soon end up becoming a horror itself (feel free to let me know if you did something like this and how it worked out): My office of maybe 15 developers didn't have any sort of formatting standard across our C++ codebase, so depending on the component, some stuff was LikeReadingJava(), other stuff was more_like_plain_C(), with some things indented with tabs and others indented with 4sp. When editing something I usually just reconciled this by going with whatever the majority of the file/component used. A few weeks ago we started fleshing out a basic formatting standard, and recently started enforcing the more significant bits (mainly indentation and such) through the "astyle" utility on all commits -- if a commit fails astyle then it doesn't get into the main tree until it's fixed and resubmitted. It's pretty clunky but there are at least no longer any individual files with a horrible mix of everyone's favorite style and indentation (yes, some files effectively had randomized indentation).
|
# ? Nov 25, 2012 22:53 |
|
Otto Skorzeny posted:Clay is more promising than Rust imo
|
# ? Nov 25, 2012 23:04 |
|
Dicky B posted:On a more serious note I have to look at other people's code a lot, and it is difficult. The nature of this difficulty usually has nothing to do with the trivial details of their coding "style" such as the names of temporary variables and the lengths of functions. It is higher up, in the way the program is structured, how things are encapsulated etc. When I see a codebase full of 3000 line functions my preferred blanket rule is "Don't do that or I'll break your fingers." Good style doesn't fix bad code, but bad style makes it worse.
|
# ? Nov 25, 2012 23:38 |
|
Otto Skorzeny posted:Clay is more promising than Rust imo
|
# ? Nov 26, 2012 02:08 |
|
Edit: nevermind, beaten.
Freakus fucked around with this message at 02:37 on Nov 26, 2012 |
# ? Nov 26, 2012 02:31 |
|
Zombywuf posted:When I see a codebase full of 3000 line functions my preferred blanket rule is "Don't do that or I'll break your fingers." Good style doesn't fix bad code, but bad style makes it worse.
|
# ? Nov 26, 2012 02:48 |
|
The Art of Readable Code is a great book.
|
# ? Nov 26, 2012 02:50 |
|
hobbesmaster posted:So longjmp is cool? I've found it useful to implement exception handling in C libraries. It's a tool, and if it allows you to write cleaner code, it's worth using. This is the same reason to use goto, function pointers, anonymous functions (in languages more powerful than C), iterators, etc.
|
# ? Nov 26, 2012 03:38 |
|
Cocoa Crispies posted:I've found it useful to implement exception handling in C libraries. It's a tool, and if it allows you to write cleaner code, it's worth using. This is the same reason to use goto, function pointers, anonymous functions (in languages more powerful than C), iterators, etc. Exactly. The bottom line is that code should be expressive. It should communicate, it should tell a story. Arbitrary guidelines about style are popular because they're easy to teach. Teaching someone to be expressive isn't easy in natural language and it isn't any easier in programming languages.
|
# ? Nov 26, 2012 04:40 |
|
|
# ? Jun 5, 2024 06:32 |
|
http://www.daniweb.com/software-development/cpp/threads/440954/cant-fix-error-in-my-program I don't even know what the gently caress
|
# ? Nov 26, 2012 08:11 |