My "Coding Standards" for my dev team

1.) Every developer thinks or have thought their shit don't stink. If you think you have the best code, submit it to your peers for review. The results may surprise you.

2.) It doesn't matter if you've been working here for a day or ten years. Everyone's input is valuable. I don't care if you're the best damn programmer. If you ever pull rank or seniority on someone who is trying to help, even if it isn't necessarily valid or helpful, please have your resume ready to work elsewhere.

3.) Every language is great and every language sucks in their own ways. We don't have time for a measuring contest. The only time a language debate should arise is for the goal of finding the right one for the project at hand.

4.) Comment your code. We don't have time to investigate what the structure and purpose of your code is when we need to extend upon it.

5.) If you use someone else's work, give them the credit in your comments. Plagiarism will not be tolerated.

6.) If you use flash, you will be taken out back and shot. If you survive, you will be shot again.

7.) If you load jQuery for the sole purpose of writing a simple function, #6 applies.

8.) Unless it is an actual picture, there is little to no reason for not utilizing CSS. That's what it's there for.

9.) We don't support any version of Internet Explorer and Edge other than the latest versions, and only layout/alignment fixes will be bothered with.

10.) If you are struggling with a task, reach out. While you should be able to work independently, it doesn't make sense to waste your time and everyone else's to not seek assistance when needed.

11.) I'm serious about #6 and #7. Don't do it.

#6 and #7 made my day :D

6)
Whats a flash?

How can I apply there?

#cannon; ++ for you good sir.

This is great.

I think I'm going to grab all of it (credits to moody according #5)

I think #9 pleases me the most. I won't protest if we have to support IE, but at least make a definitive decision about it. Most projects I've worked on so far has been "would be nice if you can, but not required, but see what you can do" about it. It's a great way to make the product support IE for a couple of months before we say "screw it" and basically start over.

#4 and #5 kinda suck tho

@host127001 Requiring your code to be well documented and to not steal other people's work sucks?

@ArchLinux CTO ?

Gonna save this somewhere

@JMoodyFWD Requiring documentation via comments sucks. I don't quite get what stealing others work means. Like copypasta something from SO, or something that's already in the code base?

@host127001 Obviously if you provide documentation outside of the code itself that's fine, but it's downright stupid and lazy to not have simple one line comments to outline a particular function/object/class/etc to give it proper context to someone else who may need to go through it. Write your code as if someone else has to understand it. That's not an unreasonable requirement.

And you need a definition on what stealing someone else's work is? How about taking a class/framework/function from a 3rd-party, stripping their credits and passing it off as your own? Seems pretty straightforward.

@JMoodyFWD The code itself (and the tests) have to be docmentation enough. Where I work comments are actually strictly forbitten.

Seems like a lot of work. More than just use that framework. But you are right. If you actually do that you should credit the author.

@host127001 The code and tests have to be documentation enough? Comments are forbidden? Wow...

I mean, what are we accomplishing by eliminating comments? A few bytes, sure. But what else? If comments are so vilified as to be exiled completely from a workplace, why bother allowing comments in the language to begin with?

The most common reason I get for not using comments is "if the code is clean enough, comments are completely unnecessary". To which I ask them to define what "clean code" is. The problem is that the very definition is subjective. One developer's "clean code" is another's disaster. Comments help to level out the subjectiveness with clear, concise notes.

The other main issue for any developer looking through your code, including yourself, is that no matter how clean your code is, clean code does not always define the intent of the code. If you code something without comments and even once ask "why was this put there?", it's clearly demonstrated that something as simple as a single line of comment could have saved time understanding the intent of the code, and as we all know in this industry, time is money.

And let's say you are very good at understanding intent within code. Awesome and kudos to you, but how long can your memory retain something you saw hundreds of lines above when that function is referenced within another?

Comments also prevent the intent of the original code from becoming unclear through modifications, leading to unintended regression.

Shunning comments as some dirty, evil concept accomplishes much, but nothing significant I can find overall as positive. The intent of your code is not clearly defined, is not well preserved and makes introducing new developers to it more difficult than it needs to be. And the reasoning for abolishing them in my opinion comes from nothing but an arrogant, narcissistic mindset. It's like saying "fuck comments and fuck you if you can't keep up with my awesome coding".

@JMoodyFWD it forces us to write clean code and it's very understandable. There really is no need to introduce comments and the only thing they do is make it easier to write shitty code. We have kinda strict rules (like no function has more than 10 lines or more than 3 parameters) so for us there is not that much room of interpretation on what is clean code.

To be completely honest. I think some Javadoc on Interfaces would not hurt but in the implementation comments only lead to worse code

Amen 🙏

@host127001 but again, what constitutes "clean code" and "very understandable"? What constitutes "shitty code"? It's very subjective terminology that so far has only been backed by subjective reasoning.

Take devrant for example. If any of the website or app's functions have more than 10 lines or 3 parameters, does that mean the code is automatically demoted from "clean" into "shitty"? It just seems like these "standards", if they are really this strict, can have the tendency to force you into a small box you can't get out of without destroying it later on.

I'm just as much a proponent of short, concise code as the next guy, but sometimes that is easier said than done, if at all possible.

Let's say that I want to build a universal mailer function. Obviously I want the delivery method, recipient email, subject and headers as parameters, and the function offers multiple methods. Because that has 4 parameters, is that shitty code? And say I make a function for each delivery method, then call to the appropriate function based on core configuration. While I've shorted each function length considerably, I've still got multiple functions that can be combined into one function, which can require editing multiple functions rather than one when parameters need to be added or changed. I mean by your definition, it's cleaner code, but is it really more efficient for maintenance in the future? Just an example of the top of my head, but there are many other situations that this could apply to. Saving a miniscule amount of processing time doesn't necessarily make it worth the added management hassle.

How does your code self-define the intent within it? Code tells you how something is done, but not always "why".

If you get a developer who is very gifted in their work, but can't understand your style of code, does that mean they're a shitty programmer because they need comments to understand it, or does the responsibility lie within the standards themselves being narrow-minded?

@host127001 Also to clarify. It's not my intent to be confrontational, but to understand more from your perspective.

@JMoodyFWD I guess our definition of Clean Code kinda is code that documents itself. Our standards help us write such code.

For example a method that takes more than 3 parameters probably does to much and should be splitted into smaller methods. Or it can be solved through object orientation.

The "why" can often be expressed through function and variable names. Comments simply don't add anything to that. Add best they repeat what the code already says. At worst they lie. Of course there are some exceptions to this (mostly workarounds for strange bugs in libraries)

If they don't understand my code it's probably because my code is shit and I have fucked up

The Eleven Commandments.

@host127001 with your reasoning more fleshed out, I can definitely understand and appreciate it better. Ultimately it's up to the team to decide the most coherent way to proceed, and since it seems there is a standard in place to ensure consistent programming, if no comments works, more power to you.

Our team frequently is handing off work to a client's in-house team or publishing it for use by customers to extend it, so because our ecosystem is very open-source and our work is shared externally, comments are a must. We also get people of varying experience, so the comments help the newer ones understand what is going on, and it helps to reinforce what they learn, as they learn.

Sounds great!

#1 and #2 are my favorites. I hate people that think they the best and environments where you have to "deal with it".

@JMoodyFWD I guess for externally shared code Javadoc etc. really is a must. For me comments on the implementation however just bring no advantage.
On the other hand this is the only way to code in a professional environment that I know. Maybe on other codebases than the ones I work one comments can actually help. I just don't see when and why

#s 6 & 7 killed me :-p Great compilation, though!

@Kulijana You're hired

The ten virtues of software engineering.

Amen!

BTW I like the recursion at 6) 🤗

Words to live by
#devlife

#9 is the most underrated ones i feel

We need a flyer with these rules !:)

@vhoyer but it was a joke ;-; (but I do want ppl to read de Readme)

@vhoyer A one line "framework"? That's a bit of a stretch. It's also in really bad taste to advertise yourself on someone else's rant. Make your own to share your stuff.

If leeching on others for self-promotion is how you conduct yourself, I wouldn't hire you and I'd advise others to do the same.

@dfox

@vhoyer You didn't present it as a joke in your comment, it came across as an advertisement. Because of that, the FIRST thing I did was looked at the code. Only then, after all that did I look at the first paragraph of the readme, said "wow, fuck this guy" and came back here to downvote and report your comment.

If this is your idea of a joke, you should probably stick to writing python. You have a better future at that.

@JMoodyFWD hey man, sorry for everything, my my joke was to make it look like an advertisement. I mean, the hole point of this "framework" is to be a joke. 😔

I don't blame you, you have a good point.

you know what, I'll make a video advertisement that looks like a joke for not have this problem next time I find it suitable.

Conveying certain emotions/voice tones thorough only text is shit... anyway, best regards for you.

Loved this until i reached the bit about Edge. This is a bit hypocritical if you think about it. WebDevs don't support edge because it is from MS (and relates to IE). This leads to users not using edge.. Then webdevs make fun of edge for not having a lot of users and use that as an excuse to not support it. If front end developers were real "developers" and worthy of the developer title next to their name, they would work hard to support all potential users regardless of the browser they use.

Now feel free to come and shoot me 😁

@MrCSharp How is it "hypocritical" to only support the latest versions of IE and Edge, rather than go back several versions to support a buggy, inefficient browser that fails to follow and accept web standards?

"Real developers" follow web standards. MS hasn't for years and is just now starting to play ball with Edge, hence why only the latest version is supported. Plus, less than 5% market share makes wasting time and money to make everything pixel perfect just plain silly. If a client wants full IE/Edge support, you can be sure they will be paying for it.

@MrCSharp and web developers not going out of their way to cater to Edge isn't what makes people not use it. It being a browser from Microsoft and them having a history of making shitty browsers is what causes people to not use Edge.

@JMoodyFWD it is hypocritical because of this: "and only layout/alignment fixes will be bothered with"... So if you notice a bigger problem on edge you won't fix it... At all. This shows how much you truly care about your users. It is also why edge doesn't have many users. Site has a major issue on edge (not alignment)... Users complain, front end webdevs tell them to use chrome (because of laziness of course) so users switch. MS is following standard HTML 5 now but even that doesn't make you happy. This is why it has less than 5% market share... So yeah... You guys are being hypocritical here.

@MrCSharp the premise of your whole argument is based on you fundamentally misunderstanding what I originally posted, then hurling insults at me and essentially anyone who liked my rant, possibly thousands more developers yet to see it, all based on your misinterpretation.

You didn't ask for clarification. You didn't provide constructive replies. You rode in like a white knight for Microsoft, admonishing me as if I committed a cardinal sin, made assumptions of subjective user behavior based on a hunch all the while arrogantly trying to define what a "real developer" is.

But okay, let's break it down so you have a clear understanding, because while you're labeling me with arrogance, you are doing so from ignorance.

"only layout/alignment issues will be bothered with": If you were a front-end web developer (and if you are, you should really educate yourself better), you would know that these type of issues are the BIGGEST POSSIBLE ISSUES, with the obvious exception of JavaScript errors which is an uncommon anomaly and therefore is taken on a case-by-case basis depending on the severity of the issue and what level of UI/UX is affected by that issue.

Every web developer worth their salt builds a website for full browser compatibility. Only an idiot would think they don't if it's a product for all. However, that doesn't mean that advanced transform techniques, shadows, mask clipping and other low-level, non-layout bugs as a result of a web browser with continued poor web standards adoption and adherence is going to be completely rewritten. Especially not when all MS browsers account for LESS THAN 5% of the global market share.

Google built a better browser. Mozilla built a better browser. Opera, Vivaldi... The list goes on. We don't just arbitrarily tell people to get off of IE or Edge. We make recommendations for a better browser that supports all web standards. MS continues to earn their bad browser reputation. Don't blame web developers for MS's mistakes.

@MrCSharp and if you want more reason why we recommend people get off of Edge, look no further than it being used along with dozens of other Windows 10 methods to track your usage and beacon it MS, all so they can sell it to advertisers looking to make a buck off of you. This in itself is why nobody in their right mind uses Edge. If it isn't shitty performance, it's shitty business practices.

They had years to get their shit together and fix their mistakes, but they continued to screw up, and as a result people don't trust MS anymore. Edge may be good in performance, but their data/usage handling and previous history of having a bad reputation is too little, too late for them to fix.

@MrCSharp I also want to just clarify a bit further, because I have a feeling I may be grossly taken out of context again.

There is nothing bigger than a layout/alignment issue. That encompasses all things regarding the site being accessible.

If the page doesn't load the content in a legible, traversable manner, that's a layout issue and is high priority.

If an element is overlapping another or pushed off the page, that is a layout and alignment issue and is high priority.

If an aesthetic technique that does not affect the legibility or traversing of the website is not working because every browser under the sun except this one supports it, that is a browser-related issue and is not a priority, unless the client wants to pay us the extra time to rewrite functionality for that specific browser and version. If however that browser and version accounts for more than 5% market share, an effort will be made to make it work or a conditional workaround to pull it out will be incorporated.

We're not lazy, we're just not going to do work that isn't paid for because one browser that is barely used has a little aesthetic issue.

Honestly fuck ie it creates more work for everyone

@JMoodyFWD Nice walls of text but no, you can't spin what you originally said because it was already very clear. How I interpreted that is if there is an issue with the site (not necessarily layout/alignment like JS issues and others) that prevents Edge users from accessing an important feature/functionality of your site then you won't be bothered to fix it. No one expects you to do unpaid work, but where I work we give warranty and we fix all browser issues that prevents users from using 100% of the site unless it is out of our hands (stuff like browser security policies). So yeah, you are being lazy.

Also, that argument about tracking... please tell me you don't think Chrome is the most privacy focused browser out there and that google is working overtime to fight privacy violations in the world :) .

@MrCSharp You "interpreted" it a certain way. Keyword here is "interpreted". Well guess what? You interpreted it wrong, I tried to explain it to you better and you threw it in my face. Providing clarification and more thorough explanation on one line of text to help you understand the reasoning behind it is not "spinning" anything. You can't completely discern intent from that one sentence.

But as I've said, if there is an issue that effects the ability of reading or traversing the website, that is classified as a layout issue and of course that would be handled. Good for you and your company for supporting a browser almost nobody will use. We're not going to recode a purely aesthetic feature because Edge doesn't support it using a standard that every other browser does, especially not with less than 5% market share. I guess by your logic that GitHub dropping I support makes them lazy oo, right?

Arguing that Chrome also shares usage information doesn't magically make IE/Edge any less of a shitty browser than it currently is. That's a diversionary tactic and a weak one in an argument, rather than actually addressing.

You've clearly shown that you want to come in and insult like a dick based on one sentence that you decided to fill in the blanks for, rather than be a reasonable person and just ask for clarification, and I'm done trying to be reasonable with you. You're just an asshole and I have more important things to do than address your holier-than-thou admonishing.

It is really very interesting to read about rules in different software development teams. To my mind these rules will help your team to work effectively and to give better results.

wow all what my team requirements is learn Js , build projects the boss tells u for number one then learn java for apk editor, and ban skids but your rules id go for number 6 and make it for(each time i cant indent my code)