Bad code

When you look at a codebase, what are some signs to you that it's bad or mediocre, or that the author of it is bad or mediocre? I'm reviewing a new codebase for my new job and I've come across these things >Lack of documentation >Hardcoded filepaths >Duplicated code >Unused libraries and variables >Copious amounts of commented out code >Abandoned functions and classes that aren't used anywhere >Returning a 200 OK with an error message attached What about you, what horrors have you seen?

Anime Github Profile Picture

>>13865 You're on lainchan, chill out

>>13865 got a chuckle out of me >>13864 pretty much everything you've listed is nightmare fuel. One thing I had to deal with with some students is identifying huge chunks of copypasted code from stackoverflow/online tutorials, sometimes in the wrong context. And then the guy going "I don't understand why it doesn't work correctly" Like damn nigga you don't understand why it works at all of course you don't get a subtle bug. Even though it's a student error so it's not that bad it's still saddening to see people trying to get stuff working without even trying to understand it

>>13864 Just because people write suboptimal code doesn't mean they are bad or mediocre people or that all the code in a code is bad or mediocre, most code written has technical debt and most code bases don't have metrics to quantity and qualify the amount. If you are looking for checklist then see the attached resources, however I will say this. Just because it is mentioned in these resources doesn't mean that the code is bad or mediocre code, it just means that according to software quality and other criteria the implementation of the software could be improved. Understanding why code is written a certain way and the circumstances it is written under is just as important and looking for all the what code smells or signs of bad code in it. Given you asked for personal opinions, my personal opinion is that quality and subjectively in most things depends on the level of quality evaluation you are doing with your decision making, some quality evaluations are pass / fail, others are quantitative scores of metrics out of 10 or 100%, and others are aggregate values. Some ratings are flexible and have buffering of tolerance, others are strict / harsh and have no flexibility. Asking is code bad or mediocre seems silly in my opinion, All code bases can be improved write regards to software quality, but making a cost benefit analysis or business case to so is easier in some cases then others. I prefer to quantity technical debt and possible paths to resolution. Attached resources include Clean Code by Robert Martin (specifically Chapter 17) Code Complete by Steve McConnell (parting part 7) Refactoring Refactoring: Improving the Design of Existing Code by Martin Fowler, Kent Beck (Contributor), John Brant (Contributor), William Opdyke, Don Roberts Please note while the 3rd resources is famously not for introducing the term code smell in a book, the book itself is quite prescriptive and I don't find it emulates the checklist still of the other two resources. I believe each software project should have an acceptable level of technical debt and a documented set of coding standards and metrics to quantity the level of technical debt. This isn't a static forever list and can change over time, but it is the consistency baseline that is used to determine and maintain the level of implementation and code quality for the project's lifetime. These vary per project, th Other checklists include: https://github.com/lee-dohm/code-smells List of antipatterns at https://en.wikipedia.org/wiki/Anti-pattern List of examples at https://thedailywtf.com/ List of examples at http://ww.codingconfessional.com/ List of design antipatterns at https://en.wikipedia.org/wiki/Design_smell http://mikamantyla.eu/BadCodeSmellsTaxonomy.html Taxonomy of Bad Code Smells List of Code Smells summarized on CodingHorror blog https://blog.codinghorror.com/code-smells/ List of Code Smells on c2 wiki http://wiki.c2.com/?CodeSmell Personally the worst horrors, I have seen were overcomplicated big balls of mud , with over 75 layers of different distributed components, where each and everyone had their own issues with being able to determine what the code did either because you had the binary but not the source code, or you had the source code, but it could no longer be built because it used a patched set of build tools that the company no longer had. Or because the component was written using the On Error Resume Next from Visual Basic and stopped working normally when you tried to remove it, or because the component was written in PHP 3 or Perl 4 or Python 1.1 or only worked on some old obscure OS (CP/M, etc) on real hardware but wouldn't work in a VM or emulator, other Java Modules that pulled in entire Spring Framework for one simple function to indent text, etc. See follow up post for more resources.

>>13871 Additional Resources include https://en.wikipedia.org/wiki/Best_coding_practices The attached resources Software Cancer : 7 Early Warnings Signs by David Boundy Are all Code Smells Harmful? A Study of God Classes and Brain Classes in the Evolution of three Open Source Systems Subjective evaluation of software evolvability using code smells: An empirical study Mika V. Ma¨ntyla¨ & Casper Lassenius

>>13872 Attached Resources include: Revisiting the Relationship Between Code Smells and Refactoring Norihiro Yoshida∗ , Tsubasa Saika , Eunjong Choi , Ali Ouni and Katsuro Inoue , This paper actually did analysis on Open Source Software and looked at Code Smell vs Refactoring solution. Metrics-Based Code Smell Detection in Highly Configurable Software Systems Daniel Meyer And one of my favorites How To Write Unmaintainable Code Ensure a job for life ;-) Roedy Green Canadian Mind Also available in HTML , original at http://mindprod.com/jgloss/unmain.html and Github repo with contributions at https://github.com/Droogans/unmaintainable-code

>>13873 Also see https://chrismm.com/blog/how-terrible-code-gets-written-by-perfectly-sane-people/ https://codewithoutrules.com/2017/11/07/no-such-thing-as-bad-code/ https://www.stilldrinking.org/programming-sucks Reading the books like The Architecture of Open Source Applications http://aosabook.org/en/index.html also gives you and indication of code with quality patterns and lower technical debt using open source examples. And the attached The Impact of Code Smells on Software Bugs: A Systematic Literature Review Aloisio S. Cairo 1, Glauco de F. Carneiro 1,* and Miguel P. Monteiro 2 Improving Code Quality by Yiannis Kanellopoulos & Tim Walker and Your Code as a Crime Scene: Use Forensic Techniques to Arrest Defects, Bottlenecks, and Bad Design in Your Programs by Adam Tornhill.

>>13874 Final resource Adam Barr The Problem With Software Why Smart Engineers Write Bad Code And two code quality relevant XKCDs that would have made great OP images for your post.

Thanks for the resources! Lots of great stuff here

>>13874 Thanks!!!

>>13871 Basically this. I was going to say code quality is more reflective on the company than the programmer. We write stuff we're assigned. If the company culture is about cranking soykaf code out, you get soykaf code.

>'m reviewing a new codebase for my new job and I've come across these things Forgot to add, you're going to be a very sad person at this company. The have soykaf code? Welcome aboard Lain, your first assignment, extend this soykaf pile. >try to rewrite section of soykaf Lain, why are you wasting time? This is not your assignment. >Write beautiful extension >Contractor assisged to modify it. Ruins your artistry. Wow, contractor is great! He works twice as fast as Lain.

>>13864 Most people who complain about "legacy" code are just not mature enough to understand that it takes more than 5 seconds to understand code you didn't write or in a style you're not familiar with, it doesn't mean it's bad code. https://herdingturingmachines.wordpress.com/2019/06/08/legacy-code-isnt-hard-to-read-you-just-dont-get-it-yet/

>doesn't provide comments for their functions. >uses floating point arithmetic pretty much ever >asserts in production codebase >gotos generally >load 3rd party modules/deps before native ones >loading more than you need from the deps for production code I agree with the ones you posted too OP

Learning to implement bad code is crucial to a software developer. It can make you indispensable when no one can understand or work with your code except you. Some design patterns y'all should learn are: not not code, which would look like if 1 !! == 0 Just generally confusing code that has functions that are only there to confuse the reader Traps And so much more!

>>13908 why is goto bad?

>>13908 I think it's better to have asserts in production code actually, at least if you don't mind the performance hit, it's better to crash the program rather to corrupt some data for example, or output something meaningless. Also not sure why you hate on floats, they are good if you want to trade precision for speed (like in gamedev).

goto being bad is actually part of the little history of Computer Science. I could tell you but there's people out there who can do it better than I do. Also, look up "goto considered harmful" https://stackoverflow.com/questions/46586/goto-still-considered-harmful

>>13908 I'm a professional C developer and good places I've worked use goto and asserts in production. goto is closest replacement for RAII in standard C. They can be bad if you use them for arbitrary control flow instead of if/for/while etc. but people who thing goto is bad period are idiots. assert is the closest replacement for uncatchable exceptions in C. There is a bug and the system is now in an invalid state and it's not safe to continue. comments are also controversial. People who obsess about comments are normally people who try to read the comments instead of the code. Don't do that. Most of the time if code needs a comment then you should refactor the code so it's obvious. After that your code shouldn't have many comments.

>>13919 who the fuarrrk actually cares about goto your language either doesn't have it or you know when to use it I think goto is only considered harmful because big companies hire people who can be replaced easily. goto requires thinking so when you are day 1 on the job you will probably fuarrrk it up if pressured, consequently.

>>13926 it is not goto that is harmful, it's the company people who try to force you to write code in a wrong style that are actually harmful (for both society and to your mental health)

Having complete control of your computer is how you learn. Not having access to GOTO is bad for learning. Don't limit yourself. In practice 99% of gotos are going to be used in a conventional way and readable. After all, all control structures are just gotos/jumps that are hidden.

In C++ and any other language with lambdas, you can totally avoid goto, even for "conventional means" of exiting nested loops without ugly flags: [&]{ ... if(exitCondition) return; ... }(); Adequate compiler inlines them into nothing, return becomes a goto;

>>13938 if you have higher order functions you can just reimplement goto with continuations

>>13864 >Returning a 200 OK with an error message attached Explain this one. I still return 404 and 405 messages, but if a user attempts to use the API with a body with broken syntax, I've been returning error responses. Should I use a 422for a body with valid syntax but invalid data? Should I use a 415 for invalid data in the body?

>Returning a 200 OK with an error message attached I am not using HTTP as a protocol to communicate with my services, HTTP is merely a transport for my protocol. It is too limited and awkward to use if you try to describe modern web applications. Case of 200+error means that, as a transport, HTTP has succeeded in its function: endpoint was reached, accessible, able to process the message and respond with my application error.

>>13925 Comments should say WHY code does something not WHAT it does.

>>13864 mixed spaces & tabs

>>13925 >goto is closest replacement for RAII in standard C which is why not to use standard C >There is a bug and the system is now in an invalid state so lets just use an assert? Really? >People who obsess about comments are normally people who try to read the comments instead of the code Not sure what you meant by this statement. Commenting every function helps to make reading code more expeditious which should be an interest of any 'professional'. It also provide a degree of accountability to prevent functions from causing issues / security flaws if the code base changes in the future. It gives a narrative to the potentially abstract decision making process of the developer. I am not surprised at all to hear that you are a professional C developer.

>>13925 >People who obsess about comments are normally people who try to read the comments instead of the code. Don't do that. Most of the time if code needs a comment then you should refactor the code so it's obvious. After that your code shouldn't have many comments. I don't understand this. If you have to understood how a subroutine works to use it, then you haven't gained much. It's not abstraction if you still need to understand the details.

>>13938 The problem with goto is it can make the control flow hard to follow when used irresponsibly. Your solution is even worse, since unless you look very closely you will assume it is returning from the function. At least when you see a goto you know to watch for weird control flows.

>>13974 It also becomes obvious that this code better be extracted into a separate function. Though here lambda is alright, it's obviously indented and I'm sure I'd notice this alien []{}(); compilation slowdown operator at the beginning of the block.

>>13987 This is why Common Lisp's return-from form is useful. Instead of having an implicit return from the nearest enclosing function you always specify the name of the function or block you are returning from.

>>13971 I'm not the person you're responding to, but I see so many people write useless comments that become outdated and thus wrong. They add line noise and disinformation when I am trying to understand the code. Consider a simple abstraction, the abstract factory. Let's say that we have the following classes. >IButton >IGUIFactory >WinFactory >OSXFactory >WinButton >OSXButton The IGUIFactory class is the abstract factory. The WinFactory and OSXFactory classes are the concrete factories. The WinButton and the OSXButton classes are the concrete objects that are created by the factories. There is no reason to comment any function inside of the WinButton or OSXButton classes. If you feel the need to comment some function, you would comment the functions in the IButton or IGUIFactory classes. Even then, you probably could get away without commenting either of those if the names of the functions describe what happens. If the name of the function is OnClicked, do you really need to comment on what is happening in that function? Unless it is exceptional, you probably don't need to call it out. People like to complain about there being no comments in code, but the truth is that you don't need comments in the code except in exceptional, hacky situations (e.g., the famous fast inverse square root code) or when documenting public APIs that you will be generating documentation for automatically. The more valuable comments are actually full documents, describing the key entrypoints, the major abstractions, and the set of sequence diagrams that describe the system that you have built. Examples are helpful here.

>>14048 >or when documenting public APIs that you will be generating documentation for automatically. That's the point. If you write code bottom up, you end up commenting and documenting every function because you're just stacking libraries.

I write bad code on purpose just to scare people like you.

boolean foo(bar, baz) { if ( bar > baz ) { return true; else return false; } Instead of boolean foo(bar, baz) { return bar > baz; }

>>13864 This: function() { code }

>>14190 Nice t. Terrible programmer

>>13940 Undelimited continuations are the functional equivalent of goto with the same issues.

>>13955 >modern web applications There's your problem. The web was never meant for such soykaf. Stop trying to force it.

>>14190 boolean foo(bar, baz) { return bar > baz; } instead of (bar > baz)

Mods deleted my complain about them deleting my post. I hate you mods so fuarrrking much

>>14211 Stop. Read the rules again and then come back.

>>14211 I won't delete your complaint for this post, but please take all future complaints to >>>/q/ . Reminder If you break the rules we will delete your post. Do it repeatedly and you'll be derezzed. Always argue in good faith and avoid using personal attacks. You should always elaborate on your opinions rather than just spilling the soykaf. Do not whine and cry about 8chan, lainchan.jp, "quality", "invasions", "new users", mods, bans, or kalyx outside of /q/.

>>13864 >non idiomatic code >abusing let statements in functional languages by "clobbering" names repeatedly >(str "something")

is this bad code? can i get internship with code of this quality? https://pastebin.com/xmgwWvkF(Don't use an external service to upload a program of yours, unless it can't reasonably be avoided.)

>>14220 Do not use single letters as variable names. It makes it easier to read and understand if the variable names accurately describe what its purpose is.

>>14220 if you tried to obfuscate what your program does, then you did a great job and it can be considered good code. If you however hope that your code will be read and used in the future, I have no idea what it does and if I was someone from your team I wouldn't waste my time reading it.

>>14220 google list comprehensions.

>>14220 Also I doubt you'd be able to get an internship with some simple python code. Market's oversaturated.

>>14253 Well on one hand the market is over-saturated on the other I can't count the times that I met a "professional" programmer who in reality couldn't code at all without an copying code from stackoverflow. I guess if you want to learn you are still better than half the professionals out there TM.

>>13864 long runtimes ... quickly and naive implementation without thinking! Don't waste your time and rewrite code 10 times, think about it and consider the runtimes.

>>14260 Thought was pretty accepted that what you buy with a senior programmers isn't really higher skill but their large private code collection with premade solutions. As much as you keep learning new stuff you also lose equally old knowledge be it from lack of use or simply getting outdated. Certainly don't feel smarter having done this now for 11 years.

>>14282 I thought it was maturity, the ability to navigate office politics, the ability to weigh quality of output with speed of output, and other general soft skills.

>>14279 don't you learn faster and have a way better understanding of the discipline ?

>>14324 Depends, some people just give up rewriting their code and let it be soykaf. The problemis that many "programmer" just code their way through and dont think about runtime, modularity and stuff like that.

>>14343 I often make an initial draft of a program/module without much forethought, and then I produce a design and rewrite based off of what I learned. On one hand it feels wasteful with relation to my time, but on the other hand it works reasonably (What I feel to be reasonable, that is.) well.

>>14351 if it works for you good.

>>13864 >no >fuarrrking >comments

the same function/class implemented multiple times in different places across the codebase, that isn't parameterised so none of them do exactly what you want so you have to add yet another one or refactor an existing one

>>14377 Or even worse, comments that just say useless crap like >please work or other instances of the original programmer basically talking to themselves. Always irritated by too much of that, especially when there's not any actual documentation in between.

>>14385 worse (and a real example): the same block of code that's copy-pasted multiple times in different places, that is slightly different so to pull them out into their own function you'd first have to produce your example of bad code, and then carefully diff the functions

>>13925 >assert is the closest replacement for uncatchable exceptions in C. There is a bug and the system is now in an invalid state and it's not safe to continue This is so wrong. You don't seem to know what exceptions, catchable or uncatchable, are. They happen whether you check/assert things or not. Trying to "create" exceptions by checking assertions points to bad code: "we don't know what we are doing, so let's put tests in the code just in case the computer goes crazy". The computer never goes crazy.

>>14421 >exceptions happen whether you check/assert things or not. Not in C, because C doesn't have exceptions. What you are replying to is "assert is the closest replacement for uncatchable exceptions in C". For catchable exceptions, in C, you'd more likely use goto, because what you really care about is separating out your error handling. >"we don't know what we are doing, so let's put tests in the code just in case the computer goes crazy". The computer never goes crazy. heh, when I put stupid words in this guy's mouth, he sounds stupid. Let's try putting smart words in his mouth and see if he still sounds stupid: "we can't reasonably know that this software is correct, and will always be correct, or that its assumptions about other software it works with will always be honored, so let's put tests in the code so that we can be reliably informed of incorrectness, and without letting the program continue since it (at the time of the failing assertion) has been shown to be in error." hmm. Not as stupid anymore. C's just not a very good language, so C's "the closest you can get to [good feature]" are rarely that good either, but C assertions are much closer in effect to pre/post assertions in Ada, which are amazing for sussing out bugs. Competitive with dependent-type languages for the benefits you get. They come at a higher operational cost since they add to runtime work, and with lower reliability since you don't see errors in code that isn't run. OTOH, they're much easier for programmers to understand and express than dependent-type constraints, and pre/post assertions can reuse parts of the very code base that they're testing.

>>14421 more: https://sqlite.org/assert.html ... I thought there was another article against rewriting SQLite in Go because it lacks an assert(), but it turns that article was rewritten into this one.

>>14423 >C's just not a very good language It's more that it's not a very good language for most tasks. It still excels at what it set out to do; being as low level while still being portable

>>14423 >C doesn't have exceptions See >>14427 - my point is that C doesn't have exceptions. Justifying bad practices with "the closest thing to" reeks of self-righteousness and lack of professionalism. Again, you don't create "the closest thing to" by bolting something, anything, to a language that is by design unable to do it. I don't know how you program, and by the looks and aggressiveness of your reply I don't want to know. You have the task of ensuring a program works, no matter what happens, assuming the hardware works, and that means all the functions called check their arguments and raise exceptions (oh wait, not possible), return error codes. That reduces C to the if (error) hell, as the kernel developers know (and love, by choice), but my point is that is that it's disgusting to use concepts that don't exist in the context. If a kernel developer ever said "oh we have *close to* exceptions now" Linux would have skinned him. The closest thing to is not the thing, no matter how you choose to put it. What you are doing is peppering the code with "this can't happen" statements, which is bloody unprofessional, and that logic must go into each function. Again, the computer does never goes crazy, and your "we can't be reeeeeasonably correct that our software works" is a sign of weak work routines, hoping that your assertions will uncover bugs. Exceptions are not bugs, you are mixing concepts. The fact that you do a little lecture about Ada at the end adds nothing relevant to your trainwreck of a reply.

>>14431 >the looks and aggressiveness of your reply I don't know how you live your life, but by the pictures of dead mutilated women that pure imagination tells me you have on the walls of the dank cave you're posting from, I think you should correct yourself. Step 1: stop trying to mind-read. Step 2: what do you even think my imagined aggressiveness has to do with how I program? This is such a bizarre thought that it almost overcomes my instant, degree-9999 irritation at you complaining about something from your own mind that you've projected on to me, in reply to a a post in which I complain about you stuffing words in other people's mouths. It's honestly a very funny image. I'm sure most people would find it more compelling than irritating. Something like, the aggressive hacker riddles his code with assertions, demanding that such be the case; the whiny coder riddles his code with thrown exceptions, demanding that somebody know immediately if something isn't the case; the tolerant programmer just gently nudges invalid states into valid states (you want me to divide by zero? that's cool. I'm going to divide by 1 instead.) >"we can't be reeeeeasonably correct that our software works" is a sign of weak work routines You have double quotes there, but then instead of quoting me, you fail to quote me and then inject a sneering insult. But I'm aggressive? This is what I said, mate: >"we can't reasonably know that this software is correct, and will always be correct, or that its assumptions about other software it works with will always be honored, so let's put tests in the code so that we can be reliably informed of incorrectness, and without letting the program continue since it (at the time of the failing assertion) has been shown to be in error." That diverges from your quote very quickly -- as early as "and will always be correct". You think non-weak work routines can protect code against someone else coming along and violating an assumption in (by then) legacy software? What work routines do you have in mind that don't rhyme with "bassertions" or "jest sweets"? Is it really good documentation plus a suite of multiple-choice and fill-in-the-blank tests so that nobody touches the software unless they really definitely have fully grasped the documentation? How many times do you readminister those tests? >The fact that you do a little lecture about Ada at the end adds nothing relevant to your trainwreck of a reply. I'm so aggressive you don't even want to know about me, and I'm also a friendly old man, chatting amicably about some soykaf that bores you to tears. I'm so sorry about this. I will try to do better.

>>14432 Steps 1, 2 and your imagination: please don't try to be funny, man. My partial (and edited) quote reflects already what lurks also in "You think non-weak work routines can protect code against someone else coming along and violating..." and "nobody touches the software unless they really definitely have fully grasped the documentation": The fact that you are selling libraries or frameworks that customers will use wrong and then complain to you. Then you will point out how they misused something and they will have another go at it, and the main point is that your product is not in error, doesn't change any of my points. In fact, it would have helped if you had said from the beginning that you use assertions defensively. They are still not exceptions. If you don't have control over how others use your software and draw the "real world" card, I raise you the "idea world" card. I'm talking about how things are: C has no way of doing exceptions. Assertions are not exceptions, and exceptions are not bugs. The fact that you are locked into C for whatever reason and that you don't have control over how others use your product introduces distortions that you have translated into bad software practices. Very well, but don't call them exceptions. Yes, really I don't want to know about that twisted real world. Now you are misquoting. I didn't say Ada bores me. I said your little tirade about how other languages have other mechanisms was irrelevant. Use Ada then if you can convince management, or don't drag it into the discussion. And I call you aggressive because you called me stupid, and sustained that when your commercial compromises are factored in to what I said, they make more sense. I'm just glad I don't have to work like that.

>>14437 >your little tirade about how other languages have other mechanisms was irrelevant hmm. that's odd. "but C assertions are much closer in effect to pre/post assertions in Ada," oh yeah, I did explain why that was relevant.

>>13864 bad indentation. too many tabs or spaces and just weird looking code.

>>14551 This, especially in sql.

>>13865 I'm fuarrrked

>>14437 What are you on about? He said assertions are like *uncatchable* exceptions. Uncatchable exceptions are used to terminate early when a program can't proceed. Asserts are used to terminate early when a program can't proceed. >>13917 explained the point of early termination very well >it's better to crash the program rather to corrupt some data

Just to bring another perspective on C and exceptions, you can actually implement a very solid (IMHO) exception system with setjmp and longjmp. http://groups.di.unipi.it/~nids/docs/longjump_try_trow_catch.html

>>17124 Pretty cool stuff. For an alternative but weirdly similar example, there's exceptions implemented in Racket with first class continuations. ; current-continuation : -> continuation (define (current-continuation) (call-with-current-continuation (lambda (cc) (cc cc)))) ; exception-stack : list[continuation] (define exception-stack '()) ; (try exp ... catch catch-procedure) runs ; exp ..., and invokes catch-procedure with ; the value passed to throw. (define-syntax try (syntax-rules (catch) ((_ exp ... catch proc) ; => (let ((cc (current-continuation))) (cond ((procedure? cc) (dynamic-wind (lambda () (set! exception-stack (cons cc exception-stack))) (lambda () exp ...) (lambda () (set! exception-stack (cdr exception-stack))))) ((pair? cc) (proc (cadr cc)))))))) (define (throw exception-value) (let ((handler (car exception-stack))) (handler (list 'exception exception-value)))) ; Example: (try (try (throw 'foo) catch (lambda (exn) (display "got inner exception: ") (display exn) (newline) (throw 'bar))) catch (lambda (exn) (display "got outer exception: ") (display exn) (newline))) http://matt.might.net/articles/programming-with-continuations--exceptions-backtracking-search-threads-generators-coroutines/

>>14377 I almost always unintentionally forget to comment, however I only write code for myself.

I saw some code, in several places of the product, where there was a very real risk of overflow and it was commented: >If x overflows, it'll just overwrite portions of y, which is acceptable and will leave the program in a workable state. Needless to say, I was aghast, as it was depending on (1) being able to recognize an error condition had arisen and acting appropriately (I could conceive of at least one case where this wouldn't be so) and (2) the compiler-specific organization of memory (compilers are free to reorganize memory arbitrarily as part of optimization). Scary soykaf.

The number one worst thing you can do, in my opinion, is what I call 'accidental obfuscation'; writing code that is far harder to figure out than it needs to be. Things like unnecessary steps for simple tasks, giving everything nondescript names, inconsistent formatting, code that doesn't actually do anything, etc. I think the reason this sort of thing is so prevalent is that there's a lot of languages that accidentally encourage it by either being too idiomatic or too inconsistent. C++, Java and Perl are probably the worst offenders in this regard. Ideally, your code should be self-documenting. I should be able to read through your code and know exactly what it does just by reading it. I know this isn't always doable, especially with more complex tasks, but you should still strive for it as a principal.

unnecessary comments like cs /// <summary>Returns the current ID.</summary> public ulong ID { get; }

>>14220 Definitely not. But there's potential; in a month or two you could become halfway decent ( provided you make stuff; 5-6 projects)

>>13864 Using strings of '1's and '0's to perform "bitwise" operations on. At a world-renowned agency. Involving space.

>>14423 >For catchable exceptions, in C, you'd more likely use goto assert() just raises a SIGABRT, you can catch and (prepare to) process the error in the handler. But it's a bad idea. Error handling in C is meant to be done explicitly with codified return values, with all the (good) performance and (most people will say bad) design implications that follow. I use asserts frequently, but only with the pattern of an application that's supposed to fail fast and be rebooted rather than try tortuous paths of error recovery. For full disclosure, I hate exceptions. I think explicit error checking in the context of properly defensive programming produces much more neat and controlled code, instead of relying on weird jumps within your control flow that are often hard to track and might bring your program into hard to picture states. Also they're bloody slow.

emojis in unreadable code

>>19731 Yes, except it's easy to wrote a perl script to change all those symbols to something more readable, and plenty of techniques for deobfuscation are readily available. In fact, he's only making the code more unreadable (and therefore less mantainable, harder to debug) to himself.

>>19731 I've never in my life seen emojis in code. It's not an actual issue.

>>13864 may i add >comments in languages other than English.

>>19757 This. Volksgagen and other Doych cumpanies have often even their code written in German - not just comments.

>>13864 I don't often read code others have written, but a major issue, and a tell I'm working with a predominantly C programmer, I'll now look for is not using the standard library of the programming language, instead writing bindings to another language, typically C. For me, it's of the utmost importance to use what's already there. Don't write routines for things the language already provides portably, and likely better. I was reading a Common Lisp program in which the author used the CFFI library to write a binding to the C isatty function. It was ugly, unnecessary, and prevents the program from running under systems that don't allow linking to C. What the author was ignorant of is how Common Lisp already provides this in INTERACTIVE-STREAM-P, which does precisely what it looks like it does, returning a boolean if the stream is interactive, and so likely has a human operator on the other side. This is probably an issue more for languages such as Common Lisp than others which tend to have a culture of linking to C for minor reasons. This shows to me the author didn't really know Common Lisp, and really hadn't a place writing the program if it wasn't going to be done well. Such people write bad code and turn what could've been a beautiful program written in a beautiful language to a monstrosity with C bindings poking out of its skin like fractured bones. I don't tend to use a language until I know it, and I write this knowing that using is an integral part of learning, but I put in effort to know what I'm doing well, beforehand. It's clear when others don't, and this is a mark of bad code to me.

>>19750 it's pretty wild

>>19787 So source code chemotherapy is going to be a thing now?

>>19795 i guess so https://github.com/castrated/emojiC

>>13869 > see people trying to get stuff working without even trying >to understand it I hate it when people do this soykaf. They act like they are trying to pursue great education but don't even take it seriously. They just want soykaf to work. They expect a good future without doing a lick of fuarrrking work to ensure there will be one.

>>20781 Excuse my angry, chip-on-shoulder doppleganger. He's in a VERY ranty mood today.

Will my code get better if I write a prayer to RMS in emacs every day?

>>13864 Highly inconsistent function names for related functions. A real-world example I came across recently was the combo of setPGPublicKey() and findpublickeyUser(). Rename one to something consistent with the other, jammit. Maybe it's nitpicking, but to me it shows either a lack of planning, or a lack of willingness to fix a lack of planning. Either way it's a bad sign.

>>20789 I'm a beginner but I'm glad I naturally do this, I'd name functions in the same group something like pgp_pkset() and pgp_pkfindusr() is there a document on naming practices?

>>20790 >is there a document on naming practices? Not really, mostly it's just common sense.

>>20790 >>20791 Depends on the language too. Pretty sure the Python docs actually lay out recommendations for how to name things. With C on the other hand practically every single person has their own way of doing things. I'd recommend just reading a few style guides from large orgs/projects and picking one that you like. For stuff that isn't covered by the guide, you'll pick it up from reading/writing a lot of code.

>>17599 I agree with most of what you said, aside from the "self-documenting" aspect. I think that I should be able to read through your code and know what it does, however I shouldn't have to read through your code to know what it does, which you aren't necessarily implying by no means, but in my experience some people believe. For instance, if I have a 50 line function that does something, (if the type system isn't expressive enough) I should be able to know what it's main purpose is, and what to pass it. This may involve adding more documentation that a string should follow a certain format, or something like "the time provided must be in the future". >>20799 Yeah I think python has it's own naming style. Most other languages / large projects should as well. When in doubt, follow what other people do to stay consistent.

>>13864 I'm a beginner so i want to incorporate good practices early, by hardcoded filepaths do you mean absolute path instead of relative? Or is it something else?

>>21210 Hardcoded data, generally speaking is putting data in form of their values instead of a variable. Consider the following example: We have a procedure doing something in the "C:\" directory: (define (install-package pkg) (extract pkg "C:\") (install pkg (string-append "C:\" (name pkg)) (check-installation pkg "C:\")) Everything works fine, but let's assume you want to install your packages to the "D" drive now. This way, you have to replace every occurrence of "C:\" to "D:\", which is pain in the ass. This is what hardcoded data, and in this case paths are. Now, to avoid this, we can create a variable: (define (install-package pkg path) (extract pkg path) (install pkg (string-append path (name pkg)) (check-installation pkg path)) This way, you just pass the path once, and in every part of the procedure the path is correct. Saves time, easy to refactor: (install-package gimp "D:\")

>>21211 >Hardcoded data, generally speaking is putting data in form of their values instead of a variable. Hardcoding ought to be a shooting offense. Even for data that genuinely should never change, it's still useful to put it in a variable for testing purposes.

>>21211 Oh, that was pretty concise. I've heard about this bad practice before, but it seems like I didn't attach the term "hardcoded" to it in my memory. thank you lain.

>>21220 Even when the data doesn't change having a nice bold constant is so much more fuarrrking readable than all but the most basic of strings.

>>13864 >Lack of documentation to be honest I rarely document my code, I get paid to ship software, not teach others, if it really bothers you, write it yourself. >Hardcoded filepaths Are you sure there's not a good reason for it? >Duplicated code It's also possible to do too much abstraction trying to avoid duplication. >Unused libraries and variables Maybe it's a WIP? Maybe some weir legacy soykaf? >Copious amounts of commented out code I do this too, reminds me of thing I've tried and didn't work, didn't you say you wanted documentation?. >Abandoned functions and classes that aren't used anywhere Are you sure? >Returning a 200 OK with an error message attached Ok that's weird.

You haven't seen anything until you've worked with graphic designers who learned on the job and have no formal understanding of code. >open project >compile >2000+ warnings >"Haha, but they're just warnings Anon!" also >"Why is this acting weird?" No results for "version control". Did you mean "copying the project to a new folder every so often"? Yes, we lost weeks of work. Yes, the newguy and I finally convinced the project lead to implement version control.

>>21481 Version control? What's that? Here's 5 zip files with slightly different code bases.

>>21482 this, but without .zips multi GB projects due to assets and 10 instead of 5

````scala <literally anything>.asInstanceOf[Something] ```

>>21479 nice b8 m8 If you aren't baiting, please tell me what your company is so I can avoid it thanks.

>>21488 Freelance, so tell me why should I waste time documenting code I write and maintain 100% and on premature optimization.

>>21508 If you're the only person involved, then you do what you see fit. I find inline documentation useful for maintaining my own code in the long-term, but if you don't then don't. If you're writing code that will eventually be maintained by others, then you're a cunt if you don't make it maintainable and are doing a poor job which will negatively impact your client and hopefully make it harder to find future work. >inb4 so what? ethics are ghey You're allowed to be a cunt.

>>21479 >to be honest I rarely document my code, I get paid to ship software, not teach others, if it really bothers you, write it yourself. >It's also possible to do too much abstraction trying to avoid duplication. Have you ever tried writing a computer program like this: Use unimplemented abstractions instead of thinking hard about anything. Some IDEs will even create the empty methods and functions for you. Then you fill in the function comments and say what they do. Then you go through each of them and write how it would work in plain english comments. Then you pass through the program one more time filling in actual code. It works really well and sometimes functions can end up being one liners but if you had to think hard to make it chances are you won't understand it skimming code later. If you use the right tools you can autogenerate manuals and they'll even integrate into your IDE. I know people don't all do it but I don't know why it's so easy and the things it makes are so easy to use.

>>21511 To further this. If you want you can even stop before writing code and create tests based on what you have and enjoy the benefit of having them when you're debugging your actual program.