Slashdot Mirror
Ask Slashdot: What Makes Some Code Particularly Good?
itwbennett writes: When developers talk about what makes some source code particularly 'good,' a handful of qualities tend to get mentioned frequently (functional, readable, testable). What would you add to this list?
When it's mine.
Not being PHP would have to be in my top two list for what makes good code. Not being Visual Basic would be #1.
"Murphy was an optimist" - O'Toole's commentary on Murphy's Law
Doesn't every self important developer think that their own code is the best?
How many managers does it take to reach a decision to begin a study to determine whether a light bulb should be replaced?
I'll see your senator, and I'll raise you two judges.
Not encumbered by patents, NDAs, or licensing restictions the keep me from making good use of it.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
Code needs to fail in an easy to understand and predictable way. If possible and practical provide descriptive and easy to follow details through logging or return values...
And say "thank you, my past self for making this so easy to understand and versatile!".
Code that you can change, and the change does what you expected and did'nt ruin something else in a seemingly unrelated place.
Doesn't matter if the code is otherwise butt ugly, as long as you can do this, the code is good enough to be workable.
Good code feels obvious and self-evident, as though its design springs directly from the problem, rather than from the cleverness of the developer.
Good code is free of regret; regardless of how much it's been modified and refactored, it feels as though it was written in a single sitting, by a developer who somehow knew the right way to do it already.
Good code is not just readable, but inviting. It feels as though there is no wrong place to start reading it.
Good code doesn't have a single goddamn class named "Manager".
The opinions stated herein do not necessarily represent those of anybody at all. Deal with it.
That it works.
Lots and lots of GOTO NNNN and I know it's good code!
-The wise argue that there are few absolutes, the fool argues that there are no probabilities.
Mathematics and calculus have given us many tools (domain and range calling back) to know for a fact whether something will work or not. That being said, most errors occur from the human side of things, although, technically, we could prove that code worked w/out having to provide real world data.
When it works.
No, seriously, that's the prime criteria. I'll take crap code over good code anytime, it it works and the "good" code needs some arcance and/or bizar setup procedure that I have to put up with to perhaps get it running.
Point in case: WordPress, a PHP driven Web CMS that today runs about 20% of all websites, is a huge pile of typical PHP spagetti. And don't even get me started on the data model ... the WP crew probably doesn't even know what that is. Anyway, just the other day I spent two hours hacking the login template to coax it into not getting in the way of an auto-login feature built with Active X and JavaScript (...don't ask, the customer spends 150 Euros an hour, I'm sure as hell not gonna make stupid remarks on all this).
I mean, just look at it! (Surgeon Generals Warning: Looking at WP code can cause instant heart problems and depression!)
It was quite an adventure.
However, it works. My grandma can setup WP in 10 minutes. Come around the corner with your flashy new Java whatnot, clean model and all, if I spend more than a week trying to get it runing on Debian or some other widespread Linux, I will ditch it, no matter how well the app itself is coded.
Programms are for users, and they have to work. The rest is icing. End of story.
We suffer more in our imagination than in reality. - Seneca
Personally, I like speed. It must be fast, you can comment out a nice readable version, but the one to be compiled must be fast.
Testability is critical, but it's pointless without actual tests. By tests, I do not mean a single test case verifying only the "normal" path where everything goes exactly as expected. I mean testing every boundary case, varying degrees of complexity where applicable, and failure modes, ensuring that it fails in the way that it is intended to fail and in every case where it is intended to fail.
I think i can shed light on this subject, having several years experience in this field. New programmers and seasoned alike often make this mistake, either through carelessness or ignorance. When working to write good code, you must make sure to set good="yes" or good="veryyes." ive written code for 20 years now and this has only ever failed me in PHP. Apparently the language does not support "good" code.
Good people go to bed earlier.
Fast; efficient; not bloated; not buggy; respectful of the user's privacy; hardened with regard to hacking if that's relevant; not encumbered by dependencies; adequately featured; well supported; well documented for the end user.
As far as I'm concerned, if you can't hit those 00001000 or 00001001 targets, you should be looking for different line of work.
Of course it is lovely if it's easily read code, well commented, well structured -- but if the former list is covered, I'll give the 00000011 latter a pass.
I've fallen off your lawn, and I can't get up.
If you have no rhyming variable names, then your code sucks. 1 stars
If you have one or two, it is barely acceptable. 2 stars
Half rhyme, then 3 stars.
If most, but not all, rhyme, 4 stars.
If every single variable rhymes with at least one other variable, you have a great job, 5 stars.
To get the coveted 6 stars, all the variable names have to rhyme with each other.
excitingthingstodo.blogspot.com
Assembly inlining is good if you're writing 'clever' (DO NOT WRITE CLEVER CODE) code.
What is art? If I live by that principle, I'll never write a line.
Some code is small enough that it's feasible to prove that the code is correct, assuming that the underlying hardware, libraries, operating system, etc.. don't fail. For example, in most languages you really don't need to put error-checking in code as trivial as this pseudo-code:
boolean isGreater(int a, int b)
{return (a>b);}
Sometimes, particularly when running in "small/tight" or real-time environments or when security is more important than debuggability, you may want a failure to be nothing more than something basic like "return -1" or "turn on aralm and halt the CPU" or even "flush caches, destoy security keys, and power off."
But you are corrent, in most cases good souce code will have good, clear, easy-understand debugging code.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
This type of article comes up continuously on /. and without some concrete defining attribute asking what model/version/etc. of "X" is "Good" is going to turn into a poll.
I would consider "Good" code to have the following attributes:
1. Runs under all operating systems and platforms
2. Source code is readable (note, this does not mean "Well Commented")
3. Takes up the minimum amount of space
4. Operations execute either apparently instantaneously or provides a progress bar for the user
5. Installs quickly
6. It's operation is intuitive
7. Does not share user information
8. Supports many/all user languages
9. Does not have extreme licensing conditions
10. Is free
11. Source code available
If I thought about it for another five minutes, I could probably double this list.
And, it's *my* list of what I would look for in "Good" software, I suspect for anybody else here, YMMV.
myke
Mimetics Inc. Twitter
When it's written by a gender and race balanced team, in a positive, multicultural environment, then it's good code!
That is... as brief as it can possibly be to accomplish the stated goal. Very simple.
I also like it when the code is commented properly so that every operation is broken down and and annotated to explain what it is doing.
This lets me go through the whole program and see what it is doing and the way it is doing it very quickly.
The code that makes me crazy is the rube goldberg code that does some thing very simple in the most elaborate way possible, has no annotations so I have no idea what the actual point of the code is, and then to make things worse various parts of the code will randomly switch between doing different things for no reason.
THAT code I hate. I see that shit and I delete it and write over myself.
Part of the problem is that people don't know how to do somethings. They understand the language but they haven't memorized the really short code snippets that are the ideal way of getting from point A to point B. And that's just something a programmer should either have memorized or stored somewhere for recall.
Using those code snippets tends make the code far more elegant and much more readable because you can see beyond the annotations what they're doing because you recognize that snippet.
If they never use them, that is fine too... just so long as they don't make their code look like that breakfast making machine from Chitty Chitty bang bang. If they do that, I will murder them all. :-D
I've decided to stop wasting my time responding to AC trolls/sockpuppets... so if you want a response from me... login.
...not having your fucking article spread across 9 pages with about one paragraph per page. That would be a great start!
For newly written code, things like readability, testability, and maintainability all can come in to whether it is "good" or not
For legacy stuff, Good code is code that works. Who cares how easy it is to read or test as long as it works?
The second one should also include "immutable". If it's hard to understand it will evolve easily to non working, and time spent on improvements can start to creep up very fast.
I have worked in very clever, solid code, but not easy to read. It was then maintained and extended by average, but competent programmers down the road, and turned into a big mess, only because it was so hard to understand.
In my experience, good code is easy to read, above all. That will make it easy to extend it coherently, find bugs and stuff. Also, if it doesn't work OK, it's easy to find out why. The single metric that saves time, money, and improves quality down the road is readability. Eveything else should be suject to that.
And, about the last point in the "article", "efficient", it's nonsense. Premature optimization is the root of all evil. You should _always_ follow the second rule of optimization (see http://c2.com/cgi/wiki?RulesOfOptimization ).
It communicates clearly what it is trying to do.
It doesn't, actually. Looking at that as someone who doesn't know what a CRC32 is I have no idea why it's doing what it's doing. Some actual useful comments might be nice.
After 5 years you can still read it and understand what it was supposed to accomplish, and it does so.
Good code starts with the right language for the job and the developer, then you have to follow the best practices for that language. How I program in C# and PHP is far different from how I program in C and ASM. The one thing that doesn't make code is abundant use of catch phrases.
not to be confused with code that sorta looks like it, but surely doesn't smell like it...
if this is supposed to be a new economy, how come they still want my old fashioned money?
I would definitely add "simple". Everybody can write complex code but it takes experience and great knowledge to be able to choose the best fit for the implementation. More experience and knowledge you have more options to choose from. Beginner will usually go with the first hunch that will get complex sooner or later as he will meet challenges he didn't expect...
So yeah, simple, readable, documented, functional, consistent...
Well, I've got to get back to work. When I stop rowing, the slave ship just goes in circles.
And this is why closed source combined with black-box development is so much safer than open source. Sigh.
I really don't mind -- actually, I think I'd be kind of of flattered -- if people were able to look at my code, go "hey, I can use that" and then proceed to use it. And in fact, I've written a fair bit of code I think would fall into that vein. I think I could write something book-length in the line of "cool coding stuff" and quite a few programmers would find it quite useful. I've been doing this since the early 70's. I write signal processing, and image processing (but I repeat myself, sorta) and AI code, with a strong background in embedded and special-purpose systems, a bunch more.
But because a lawyer might look at my code, and use it to screw me, and through me, my family and employees quite harshly?
Bang. Closed source. The opposite of furthering progress by virtue of passing along what I've learned. I give away some of my work product such as this, but you will never see my source code because of the legal environment.
As far as I'm concerned, if I wrote it without referring to "other" source code, then no one else has any claim on my work. I don't have any idea how to fix copyright and patent and still retain the supposed commercial motivation to create, but fact is, as it stands, it's completely fucktarded.
Pisses me off, it does. :/
I've fallen off your lawn, and I can't get up.
No one's even mentioned the Bechdel test yet.
_When_ was the last time you actually needed a different CRC function from the standard 32-bit one?
When trying to create unique crcs to use as hashes for 8 billion pieces of data daily so as to find them quickly. 32 bits isn't enough. 64 bits is way more than enough.
"Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
Seriously. Good, readable names for everything make code far more self-documenting than otherwise, don't cost the compiler a single cycle, and make it far easier to understand when someone comes across it five years down the road.
Other than that, I'd add methods that only perform one action, with no side effects, and that only work at one level of abstraction.
Finally, code that matches its method name - don't say "if thing.checkValues()", say "if thing.isValid()" - and if isValid() does anything like trimming whitespace it should do it on its own transient copies of things, since its not obvious that the method would ever change state.
And so on. It all boils down to code that doesn't surprise you.
You're special forces then? That's great! I just love your olympics!
Good code has documentation for knowing what it should do, and has unit tests to verify that it actually does that. If there are any problems good code can be modified to meet the (possibly changed) requirements better, while unit tests ensure the modifications do not make the code worse. Code which cannot be modified is not good code. It's that simple.
I don't care how bad or tangled the logic but as long as it's not using Hungarian notation, It's good.
Harrison's Postulate - "For every action there is an equal and opposite criticism"
There needs to be a compiler (not language) that can convert mathematical proofs to an optimized assembly listing. How it would work, the files it would take in, and who would use it - I don't know.
Their whole mindset still makes me want to puke.
Obfuscated crap. Techno-machismo teens playing games trying to get their code into the least number of characters and the least amount of memory. I've had to fix or test so much of this junk and it's still just plain stupid.
The *human* part of the system is what *matters* and that includes the code interface. First, I want comments not about *what* is happening. I can read that. I need to know *why* it was done, so I don't undo it, or I can do something different safely. Comments should be one liners, limited to "why" and sometimes "how".
If adding a variable aids readability, add the fucking variable! Shove all the results into a meaningful, readable variable name and then shove *that* into your function argument, not some long series of nested function. It's not the 90s. You don't have to save memory! Memory is there to make your code readable. Use it!
Ok, rant over. I'm going back to work now.
Please do not read this sig. Thank you.
One of the most important criteria is that good code be easy to modify. Readability, testability, elegance, and simplicity all lead back to that. When you change code, you should be assured that it will do what you expect. Bad code produces surprising side effects when you change it. Good code warns you (possibly through unit tests attached to the code) when you are doing something questionable. If you have to run the code to determine what it does, then that's not good code.
Needs evolve and change over time (or simply become clearer). Good code needs to be able to follow.
Spaghetti code is good.
With lots of meatballs.
Have gnu, will travel.
Coding a prototype of something that's rapidly changing in huge ways should be done differently than production code that's worked on by lots of different developers. One will not be optimal for the other.
In debates about Christianity, there are two groups: those looking for answers, and those looking to just ask questions.
What if the comment is // this code sucks.?
Who ordered that?
Code is good when the data structures clearly model the problem domain. The algorithmic code / control flow then follows naturally and is easier understandable.
Take all work you've written and entrust it with someone who will publish it a few years after you die and after your estate is settled or a few years after the last company that would have any claim to it ceases to exist, or after any copyrights or patents other than yours that apply can reasonably be presumed to have expired (probably 95 years after you wrote the code), whichever comes later.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
The Wayback Machine...
Or, see the Slashdot article, "Beautiful Code Interview" that discusses an entire book about the very topic.
I agree with most of the earlier posts, but the main thing I look for is conciseness and clear & consistent naming of variables. If your methods/procedures/classes/functions/subroutines are are obnoxiously long, it makes it less readable, harder to test, and just longer to debug. Modular design also lends itself to be more reusable. I've always been of the mindset to name your variables what they are. You shouldn't have to go to a comment or read the code to see what it does. It should speak for itself - even for someone who isn't super familiar with your code/project. Or at least that's what I think...
Yanno, it's been years since I've coded (beyond looking thru code to tweak a definition here or there anyway). Decades, even.
But I was taught on the job that range checking of inputs and boundary conditions was essential to reliable code.
Obligatory XKCD reference.
I can see the fnords!
When it is done by people, code can be art sometimes. I have no good example immediately available, but I mean there is a huge difference between generated code such as jquery-1.11.2.min.js and code that can be read by humans. By optimized, I mean the lowest time and space complexity during run time. And there are basic and obvious maintenance constraints that everybody should follow like avoiding hardcoded values (unless necessary), keeping it easy to read, avoiding +1000 lines routines if not necessary, ...
Regarding debates on comments vs self explanatory variables, I have no opinion on this. Depends on how it's done.
Good code does one thing well:
It communicates clearly what it is trying to do.
Personally, I'd say that good code does what it is trying to do. Great code will do that and communicate what it is doing clearly.
Code has to be AVAILABLE - this is the most important. That means it must be OPEN SOURCE.
If it is CRAPPY code, it can be MADE BETTER if it is open source.
If it is INEFFICIENT code, it can be REWRITTEN if it is open source
If it is HARD TO UNDERSTAND code, it can be COMMENTED if it is open source.
So any code that is OPEN SOURCE, even if it is crappy, inefficient and hard to understand, can be improved.
But any code that is CLOSED is absolutely useless in my opinion.
... functional, readable, testable ...
From the maintenance perspective, when you can't make the code meet some standard, comments describing what you missed and why (time, spec conflicts, didn't care enough) are helpful. This hints to the next maintainer that modifying a piece of code that missed some good-practices target has additional considerations or hidden pitfalls, or that it can be fixed/extended/replaced with impunity.
You skipped the case in which it's not unique code but for which you don't have a library.
Good code has comments for edge cases, I mean "why the fuck are you checking if foo is less than bar?" with "//checking if foo will not overflow because ..."
Edge cases are by definition very unlikely, usually the code that handles them are bugfixes. Too many times I come across code that is full of bugfixes for those edge cases but no comments whatsoever, to me those kind of comments are more important than method comments (aka javadoc).
If you need a 64 bit hash, write a special 64 bit hash function. It's only going to take a few lines, and removes dependencies on bizarre external code, like 64 bit CRC that nobody ever uses.
Besides, CRC functions aren't very good for hashing, as CRC(x) XOR CRC(y) = CRC(x XOR y)
Over-commenting is a very real problem, and CRC32 is CS101. If I was reviewing code which described what CRC32 was, I would remove the comments.
Computer Science is [a] a misnomer, and [b] more properly a subset of mathematics. I might characterize it more as giving you tools to reason about code rather than teaching coding practices. It is not generally meant to be a practical education. There is always time to learn the practical stuff, and the practical stuff changes often enough that it's not necessarily worth teaching.
I'm in the opposite camp: I'm self taught, and know a bunch about deployment and the intricacies of source control, and refactoring, but very little about, oh, algorithmic complexity or parser/compiler design. The theoretical stuff isn't quite as useful on the day-to-day as the practical knowledge, but it's much more useful when trying to learn new things. Similar to how you don't necessarily need music theory to play guitar but if you want to transpose a piece of music or pick up a new instrument, it would be pretty useful. Composing a piece of music might be more like writing a compiler. In both cases you'd be relying heavily on theory.
If you thought you were signing up to learn how to be a programmer, you've made a mistake, but it's not so bad as you think. The stuff you're learning is useful, even if it doesn't seem like it. I feel like I could stand to know quite a bit more about it myself. And the lesson is, that you need both parts, and you'll miss whatever you don't have, but you miss the practical stuff all the time, and the theoretical stuff only when it's really, really important.
Those who advocate genocide deserve every protection afforded by law, and none afforded by common human decency.
Fair enough Windows has been dominant in the PC market for decades but you can hardly say it's been dominant on server platforms for decades (ever?). Maybe for intranet use but as far as internet facing, mission critical servers UNIX, BSD and since the late 90s Linux has been dominant.
The first thing is, most of us are coding as house painters rather than as Rembrandt. So it needs to do the industrial job. I tend to put as much effort into documentation and style for my personal code as for working code.
If the code is for a micro-controller in C then the emphasis might be more on raw efficiency and preciseness. A command line utility run ad hoc with low resource usage can afford to be a little less efficient and more readable. Code for an online transaction system needs the efficiency, perhaps as a tradeoff to readability but in most cases hopefully not.
I have written code and products and have had to go back to stuff I wrote 15 years ago. So I learned a long time ago to document as clearly as possible for the poor sod in the future (i.e. me) who will have to come back and make sense of everything. Mostly I succeed here but sometimes I fail.
I also supported other people's assembler code for a few years. That provides lots of what not-to-do's.
If you are coding examples for a book or website then the rules and aesthetics can be changed again. Maybe think more Rembrandt here.
Functionally, document everything, use meaningful and consistent naming conventions, catch errors, log, provide trace capabilities where needed, be as generic as possible and think about reusability but don't obsess over it (depends on the context as always).
Elegance.
Well in this case I'd say there's Google and Wikipedia, use them. The source code is not the right place to teach someone about what CRC32 is or when, where or why you might want to use it. It's almost as bad as comments that try to teach you the programming language you're in. If you're implementing something that's not in an RFC or standard of some sort, I'd agree with you.
Live today, because you never know what tomorrow brings
I know this is a joke but my favorite comments are one like // this code sucks that unabashedly describe the merits and problems of the code. There's nothing worse than auditing convoluted code and wondering "is this code terrible or brilliant?" If the original author tells me that it's not brilliant then it saves me from exploring that avenue.
There are several metrics which can help you to identify code which is not bad. One is cyclomatic complexity. Another are connectivity metrics going over the graph your code spans. For cyclomatic complexity there are good boundaries available. However, it is a complexity metric. And complexity is not the only thing which affects code quality. Other elements are labeling operations, such as methods, functions, and procedures. There is plenty of lit. available in the area of code comprehension.
On PC platforms perhaps. Not on server platforms.
The world's burning. Moped Jesus spotted on I50. Details at 11.
A guy whose evidence is "I've seen stats", without linking to them shouldn't be lecturing about hard evidence.
The world's burning. Moped Jesus spotted on I50. Details at 11.
CRC's were in my first year of CS, in 1996.
I'm a minority race. Save your vitriol for white people.
If I was reviewing code which described what CRC32 was, I would remove the comments.
Well, you are Doctor Evil.
"First they came for the slanderers and i said nothing."
You can see it on Netcraft's "what's that site running?" -> http://toolbar.netcraft.com/si... & for showing what academic institutions run what (that could also be done for the Fortune 100/500 & really *ANY* type of servers out there).
I've used here a few years back to see for myself:
http://news.slashdot.org/comme...
& yes, to prove that very point WITH VALID DATA FROM A REPUTABLE SOURCE (2 of them, CNN list of Fortune 500 + NetCraft)...
All that happened vs. it was downmods and ad hominem attacks (the last resort of "defeated trolls", lol, & invalid proving my points all the more).
It works & since you demand it? Take a look for yourself there... get a list of the Fortune 100/500 & see what you see nowadays I suppose. That's only on servers though. There's millions of PC's out there vs. servers. What do PCs run the MOST (94++% of them worldwide as a KNOWN fact? Windows!)... you can't win on that note alone.
Facts used that way work, & I've used that before here, to shut fools up on that very account + face it: The ONLY real reason say, Linux, gets used, is to keep per unit costs down (on servers AND smartphones)
+
Face this about that much: ALL THOSE YEARS OF "Windows != Secure, Linux = Secure" is falling apart around your ears here - ANDROID, yes a Linux, proves it for me (& I love it + hate lying bullshitters/deceivers - not because I hate Linux, I don't & ADMIRE it actually as a socio-technological phenomenon that proves folks CAN & DO work together globally doing nice things for free).
You bullshitters don't realize 2 things: Your deceits shoot you in the foot, I make SURE it does (lol) & you can't EVER ever get the best of me - you don't HAVE what it'd take in truth & facts.
APK
P.S.=> However, the "noobies" inexperienced youthful stupid view here isn't aware of the fact C/C++ have been hugely successful on ALL platforms and have gained a gigantic following & momentum that other languages just do not have since time + success will do that for me (selling itself better than bs & "pr spin" that goes on around here like mad, lol, that's for sure ala my "Linux = Secure, Windows != Secure" b.s. that went on here for years)... apk
If the code has a useful function and exposes it with an interface that is no more complex than absolutely necessary, it doesn't matter how ugly it is inside. It will be used and, in time, there will be resources to clean it up. UNIX system calls, libraries and command line tools are a good example. There is not much in common between original code and various modern implementations, but code written on top of these over decades still works and both developers and users are able to leverage their experience.
Also, even the best written code will have bugs. With simple interface, it's at least feasible to write good tests and find some.
A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away.
-- Antoine de Saint-Exupéry
Escher was the first MC and Giger invented the HR department.
FACT: The PC to Server ratio is MILLIONS to 1 alone
This does not stand to even 5 ms of thinking. I am living in a country with 5 million people. You are claiming we have 5 servers or something like that.
Or if you are an american: How many cities do you have with more than 5 million people? How many cities with more than 5 servers? ...
Or ... there are about 7 billion people on the earth. Lets assume that each have a PC (many don't). You are claiming there are only 7000 servers on earth.
Code needs to be easy to understand, that's all. You can't keep a long list of priorities in your head, that simply doesn't work at all. Just keep one: easy to understand.
Of course it needs to work, but that's obvious so not really worth stating - testable is part of this obviousness, if you need to test it, and you can't, well, then it doesn't work.
Sometimes code needs to be performant, but often this is only the case for small parts of it, so it's better not to think about it or it will tend to compete with making the code easier to understand.
I'm deliberately using the phrase "easy to understand" and not just talking about readability, because ease of understanding often doesn't not come from just superficial readability tweaks like spacing, consistent styling, self-explanatory naming, etc. Often it may require approaching the problem at hand from a different angle, modeling it slightly differently or otherwise shuffling things around a bit to reduce accidental complexity and avoidable dependencies.
You want me to prove there are 7 billion people on earth?! You are more stupid than a kid in first grade.
R. Pirsig wrote a paper on the philosophical and mental challenges in defining "quality". I suggest reading it.
Dewey, what part of this looks like authorities should be involved?
> What the hell is this?
The 8th entry is set to zero so that the test can verify the table was initialized properly.
> 4))
> Why is there a block comment at the beginning that does nothing.
For alignment of CRC32_REVERSE, CRC32_VERIFY, CRC32_Table since /. fucks up formatting.
> and what the hell does that trailing comment mean?
The comments lists entries [0] and [1]. The first 8 entries are these :
i.e. 0x00000000, 0x77073096, 0xee0e612c, 0x990951ba, 0x076dc419, 0x706af48f, 0xe963a535, 0x9e6495a3,
Whenever you generate a table it is always helpful to list _expected_ values so someone can _verify_ them with _actual_ values.
Yeah, I forgot to include
I wrote a 64-bit crc function, and it worked fine over billions of records of random-length text, was extremely fast (written in c), only required 8 bytes of storage, and was thread-safe.
"Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
All this other shit is useless unless:
* the way the problem under solution is broken into solvable, understandable pieces is well chosen. Make a bad choice here and your code blossoms in complexity and fragility.
* naming and spelling is consistent. Don't show me code that has shit like "frobURI()", "tweakTheURI()" and "makeUriPretty()". Components of names must be consistent. 'do', 'get', 'put', 'fetch', etc. must always mean the same fucking thing.
When with a few tiny changes you open up whole avenues of functionality that hadn't been conceived before. Sometimes you get that and it gives me immense pleasure. It opens up potential your code didn't have earlier.
Am I babbling or does that ring a bell for anyone?
So.......bubble sort.
Contribute to civilization: ari.aynrand.org/donate
Hi APK, I knew you were a hosts file fanboi, I didn't know you were a Microsoft astroturfer as well!
// Note to self, don't feed the trolls
FYI, I didn't intend to put words in your mouth, hence why I put "ever?" in brackets (context APK, context...).
Also, if you want people to take you seriously then you need to learn how to summarise your thoughts and present them in a non-td;dr way.
Well, just comment out the code section that sucks. Job done.
There are many axis for rating software. One of them is how easily a newcomer can contribute. It measures simultaneously code clarity, architecture choices, software usefulness (who wants to contribute to something useless?), maintainers mindset...
Take your meds APK
The best code is code that when you have to go in to make a change, was built in such a way that new features just slot in nicely, with little rework or fuckery. I LOVE when code I built previously means what someone thinks will take me 3 weeks takes me 1 hour (billed at 2 weeks)
Can you honestly expect to get a worthwhile answer to this question on Slashdot?
Wouldn't it have been better to ask people to link Git repositories with examples of good, clean code instead? Better yet, make a site which allows people to link a repository instead and explain why that code is either good or bad. Let people vote as well.
I can show you massive portions of the Linux kernel tree which is both good and bad. Good because it's functional, tested and works well. Bad because it was ransacked by the spaghetti monster. Want a great example?
https://github.com/torvalds/linux/blob/master/lib/glob.c
This code is fantastic because it is rock solid and has been tested to death. It's even relatively clean, but while some people can actually use it, maintaining it would be nightmarish due to lack of documentation. It's documentation isn't entirely awful, and I really wouldn't say "replace it because it's not pretty", but it's code is simply not pretty.
It also has to be handled with care. It makes assumptions that the parameters passed are proper. Used improperly, it can cause overflows. There's no real error handling or bounds checking. It's not what I would personally call "secure code".
But it's great code all the same.... if called from a function which ensures what is passed is valid.
The best piece of code I ever wrote in my life was nearly 100x faster than the next best algorithm ever written to do that problem. That took the expected run time down from a few days to an hour.
It was not a particularly well-commented piece of code. If it were, it would have been even better.
It was not a particularly obvious algorithm for solving the problem. If it were more obvious why one would choose to do it this way, it would have been even better.
If the primary concern is runtime (because it normally takes days to run), and you literally make it orders of magnitude faster, that's good code. It could be better if it were also better commented and easier to maintain, but those aren't *always* the primary concern (yes, sometimes they are. That's the point -- criteria differ!)
[TMB]
What is missing is the word 'design'. You may comment why you made a design (or write a paper on it). You may understand the design by reading the code. If you don't it is either too complex (because there is a possibility to write the same functionality with the same complexity with easier-to-read code) or you need to explain the design for it.
nosig today
How about: it's bug-free?
licet differant, aequabitur
Perhaps he's been listening the that IBM guy from 1968.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
I think re-usability and properly formed and conceived libraries and classes if it's object oriented should be in there. I've seen plenty of people meet all 8 of those requirements, but have all their code in one giant file that really should be divided up into separate logical pieces that could be used again in other projects.
Code headers are nice, but if code is properly written and structured they can be overkill and clutter, so I don't see them as mandatory in all cases. Otherwise, I like this :D. Divide your code into separate source files using logical divisions that make sense. Then create libraries if one of the divisions gets big enough. Try to emphasize reuse.
I offer Sendmail in its mid-1990s form as an example. We had several dialup customers with Microsoft Exchange servers. They'd connect and Exchange would issue an ETRN to dequeue waiting messages. The problem was that Sendmail by default, would send a "Warning: could not deliver mail for 4 hours" reply back to sender after the email had languished in the queue that long, and they dialed in sporadically and not at all on weekends so folks who emailed them would get these messages. It was bad. I wanted to disable this warning specifically for ETRN domains but not for everyone.
Does this feature exist? Sendmail documentation defined 'queuewarn' as a global setting but did not address this "deferred delivery by design" problem. Could there be a presently-undocumented or undiscovered workaround? Delving into the source it was visually apparent the answer was no, the warning was unconditional. The only workaround would have been to run a completely separate SMTP server on another IP address with the queuewarn off, and MX 'em to that. What a bother. Are domain-specific attributes available? Yes, these had a mailer flag of HOLD. Can it be addressed with a one-liner? Yes. So the _FFR_NODELAYDSN_ON_HOLD compile/config flag was born, off by default because we don't want to break things.
Just a couple of hours to discover, patch and test. another hour to render it into a contrib patch where it made its way into Sendmail. Open source is cool and when you see your own contribution being proposed as a solution to solve someone else's problem years later... that is quite satisfying.
Sendmail had the right balance of code-to-comment. What comments were there would not make sense until you understood the underlying process, and tag names were explicit enough that comments were seldom necessary.
<blink>down the rabbit hole</blink>
crc32 is the name of the algorithm. If you dont know what it is, what it is for or why it exists, comments aren't the place to describe it. Incorrect, misleading or unnecessary comments are worse than no comments at all.
Hope it's controlling a vacuum pump.
Not a sentence!
Some actual useful comments might be nice.
Well, when the function is named calculate_crc32()...
Slashdot, fix the reply notifications... You won't get away with it...
It will come up in your Comp. Sci. education.
If it doesn't you have really bad teachers, or a really bad school.
All good programmers should understand the basics of one-way-hashes.
There is no lose or win - is this the kindergarten?
I replied to one claim and one claim only: that the PC to server ratio is in excess of a million to one. That claim is so absurd that anyone not laughing their ass off is an idiot that has trouble with big numbers.