Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
1. Indent with 3 spaces to fuck both tabs guys and spaces guys git repos.
2. Use windows line endings and laugh and laugh and laugh.
3. Giant full page ascii art intro on every single file.
4. After the giant ascii art intro there are literally zero comments.
5. Keep the bracket on the same line for getters, but on the next line for setters because fuck you.17 -
Definitely Rust, and a bit Haskell.
Rust has made me much more conscious of data ownership through a program, to the point that any C/C++ function I wrote that takes a pointer nowadays gets a comment on ownership.
I wish it was a bit less pedantic about generics sometimes, which is why I've started working on a "less pedantic rust", where generics are done through multiple dispatch à la Julia, but still monomorphising everything I can. I've only started this week, but I already have a tokenizer and most of the type inference system (an SLD tree) ready. Next up is the borrow checker and parsing the tokenized input to whatever the type inference and borrow checker need to work with, and of course actual code generation...
Haskell is my first FP language, and introduced me to some FP patterns which, turns out, are super useful even with less FP languages. -
Structure: decades of programming in too many languages to enumerate. I lean functional, but only when the language doesn't fight it. No matter what I'm doing, my code is immutable in practice, if not paradigm.
Syntax: No one thing in particular. I code differently depending on the language.
When I start learning a language, I'll find the standard style checker and create a project where I write an example of every single rule.
The end result is generally a quick intro to the language and a bonus understanding of the hot sports opinion in said language. I call this an ocean boiler.
I lean heavily into autoformatting because I've worked on too many projects to care, and I have a general expectation that something which is important enough to make a code standard is important enough to be enforced in tooling. I'd rather spend my time solving problems that thinking about stylistics.5 -
Coding style influence:
Me: Did it work?
-looks like it worked-
Me: THIS IS THE WAY!
Someone else: Yeah but that -
Me: THIS IS THE WAY!1 -
I'm not a programmer by trade, so the only language I know well is bash. But as sysadmins we do use bash often.
Looking at other sysadmins' scripts though, there are interesting things in it every so often. Like for example `touch file` which creates a file. I've seen some sysadmins just do this instead `> file`. Genius! Or perhaps a `cat file >> elsewhere`. You can do that with `< file >> elsewhere`. It's something that if I hadn't seen it elsewhere, I wouldn't have thought about. But yeah, it saves a program call and it works!10 -
The English language.
Maybe my fascination with code that reads like a book comes from a desire for my code to be understood. Maybe it comes from novelty. But it really does send tingles down my spine when it reads like literature.
That's one of the largest reasons Lua is my favorite language and Java is one of my least favorite (sounds like a guy with a bad stutter, always repeating himself)2 -
KISS, DRY, Path of Least Resistance, Three Strikes and You Refactor, early returns, no array.map when nothing is returned, only use switch when # cases >= 3.
And using var in javascript instead of let/const to piss off my colleagues (and because I understand function scope well)6 -
My first job and the amount of bad code I had to work with influenced my coding style a lot.
One thing is reading about bad examples. Another thing is it to maintain these bad examples.3 -
I know people have mixed feelings about Uncle Bob and I really never followed the guy at all, but back in college I found his book Clean Code on a shelf and read it cover to cover. A lot of it really stuck with me. In fact, I might dig it up again now that I'm thinking about it.3
-
Code Simplicity by Max Kanat-Alexander, a very short but inspiring book I've read two or three weeks into learning programming. I can only highly recommend it to beginners and probably even people who already have some experience in the field.
5 -
Rust I think, it introduced me to using iterators and monads. I try to use them wherever I can, they're so cleeaan.
-
I'd say Uncle Bob, since I ended up flying through his Clean Code book in order to get a placement job, but in reality, it's probably only partially that.
Most of my influence probably comes from the guy I shadowed under when I was on placement. He taught me way more than he probably ever realises.1 -
Random GitHub people with 0 star repos but surprising pristine code. And burntsushi cuz he is burntsushi.
-
My biggest influence on coding style is:
"If code make reviewer puke, code bad."
In all seriousness though, I think the biggest influence is seeing messy code and not trying to replicate that.
I think every code file, however ugly it is, tells you a story. Maybe the coder was less experienced, maybe it was written during crunch or the coder is an enterprise software engineer who has to make a factory for everything and everything is generic.
In my opinion there is no perfect code style. You do what's required and hopefully in your best ability, and, as a bonus, think of the person who has to look at your code next...
For me it's kind of hard to tell whether my code is good. I have no reviewer in the company, which brings the risk of writing code so only you understand it... but so far it has worked and I've definitely seen worse than my 1 year old files. 😄 -
My biggest influence on coding style is working with other people's code. I know the temptation to write "clever" code and I've been (and probably still occasionally am) guilty of it myself, but it's not until you have to debug someones oneliner iterator which has !(i-j) as the stop condition that you start to appreciate dumb, boring, obvious code.
If having a series of if checks in a long list makes it readable, keep it that way. If it makes it more readable to rewrite it into a nested switchcase with a couple of ternary bits, go ahead. Just don't spend half a day wrapping it up into two layers of abstraction that will require an onboarding process for the rest of the team.2 -
Myself. I started with PHP about 7 years ago. Most people nowadays don't really start writing vanilla code in language they are learning anymore. Everyone just want to see results and fast, I didn't. I needed everthing to be perfect from the start. It took me a little longer to get shit done as to anyone else and sometimes it really bothered me. Am I stupid? In the end it turned out, I was not *that* stupid. In the end I learned to hate half-baked solutions of these "fast" people.
Along the way, my coding style got better and better as I gained experience. In my opinion, coding standards are a good for helping you find your own coding style. You shouldn't use them blindly just because they exist. You and your colleagues should always find the optimal solution that works for you. I probably wouldn't be able to work in a company where the code is written the way I hate. It hurts when I have to write something under a lot of pressure and just glue things together resulting in a pile of mess.1 -
Literally whatever colleagues/people in the field prefer.
Otherwise, it's functionality followed by minimalism and followed by understandability. -
Just realized I don't have a code style. In python at least I stick to what flake8 tells me, but with C++ I change my style every project I work with to adapt to their existing code base, and then I keep that style untill the next project.
Current project is an ns-3 module, and their code style is quite horrible but I'm already making it a part of me.1 -
React, it's declarative way of doing things, and the functional programming methodology it prefers.
Realized how much I've moved on from for-loops and class/object instance to maps, filters and immutability/observers when I worked on a Laravel project after so long and found myself forced to do things in the, erm, "PHP" way, despite spending my initial year and a half of programming working exclusively in PHP.
Sure, there's Class Components and imperative techniques in React but I had blissfully settled into using the flexible nature of doing things enabled by both native JS and React, with hooks, Lodash/Ramda and (almost fanatically) pure functions1 -
I got my first proper start in programming through a side business operated by the same guy that was running a local makerspace. He had me learn basic git syntax and change some values in ionic.
From there I decided the best way to learn how to do this was write my own project in angular. From there I branched of with React and Vue.2 -
The first company I developed software for had no coding conventions and it was visible in the codebase of almost all of our products. This is why I follow the coding conventions for every language I use.
-
If by coding style, you mean conventions and not design patterns, then I'm surprised no one has mentioned the official documentation nor the standard library of sorts. I'm relatively new in the industry but at least I'm quick to realize that every language/framework community tend to have their own preferred style; not a one-size-fits-all thing. And these preferences are usually set off by code samples from the official docs. This is true at least for the big communities where the official docs are well-written.
-
Biggest influence was the Java coding style, where constants are ALL_CAPS and everything else is camelCase
-
Junon's Zen of Tabs:
Tabs for lexical indentation, spaces for alignment.
Tabs always come first, and never after a non-tab character.
This is the only way it should be.
I do not have an open mind about this. Fight me IRL.13 -
Mayakovsky, Malevich, Kandinsky and all that art movement.
Too bad was neither bauhaus nor Aalto. My code would’ve been much cleaner but waaaay less expressive, and expression is what I strive for. -
The devs delved too greedily and too deep. You know what they awoke in the darkness of abstraction hell... shadow and flame1
-
I only prefer { on same lines if not used for class constructors & try catch blocks..
Other than that, I adapt to the existing codebase styles, to not fuck up things further, even if it makes no effing sense (old project, styles & best practises changed 'a bit')..
So I guess I'm being influenced most by the old code and pass devs on the projects..1 -
Cocaine. Wait that's not what you meant, didn't you?
Mostly copied from YouTube and stack overflow. Someday stuck with camel case because my friends got fed up with me ¯\_(ツ)_/¯ -
Some 80s and 90s books. And the more the time goes by the more I lean towards FP and stateless systems...
On the syntactic side I love the work of Kevlin Henney. For me it's all about readability. So a lot of choices are based on that. -
Honestly? The environment... I have different styles in different languages and IDEs, for example I started Java with NetBeans that defaults brackets to same line, so when I use Java I default to same line brackets, C# on the other hand, Visual Studio defaults to brackets on their own line, and so do I.
You could see me write same code on different languages/environment and it would be styled differently. Yes I know, I should be burning in hell,I am THAT kind of guy xD3 -
When using python, almost every other linter/formatter shoves down pep8 down my throat.
I used autopep8, which has NO CONFIG FOR USING TABS. FFS. The only solution I could find is disabling indent reformatting. How is this a solution at all?
Then I found black. Black is a piece of shit. Let's move on.
Now, I use yapf+pylint. This is basically clang-fomat for python. I love it, it does exactly what I expect it to do.2 -
For most part, after realising I have freedom of implementing and structure my codebase. I have followed only this rule whenever I stumbled into new way of code format/implimentation techniques.
- Understand the structure
- Check if it's new/upcoming way people started coding
- decide should I use it just yet
- implement according.
Adding factors such as time and prefered language, it turns out to be your own personal style.
PS: yes you do follow community conversion but, there's some part of it that makes it unique to you. -
My uncle Kyle works for @creativeMISFITS and he taught me about his coding style so that's what I'm used to.2
-
Clean code and experience.. if you had to maintain a big project over a long time you’ll learn to get your own code cleaner😅
-
Depends on what style means...
How I format the code: language, team/style-check rules, IDE auto format settings
How I structure my code and design programs: experience... Mainly from blowing stuff up, having to rewrite monolith code, trying to understand other people's shitty code and why they can't seem to organize it better so you don't need to be a surgeon or God to even attempt to figure out wtf it's doing and how it works... Or supposed to work. -
My coding style is mostly influenced by good old personal preference, but also because of a certain internship where there was a lot of gain to be had by making everything as reusable and testable as possible.
I guess you could say my motto is usability, readability and flexibility:
I like tidy, reusable code with an emphasis on keeping code readable. I've always liked modular things I guess...
And I despise two things: curly brackets on the next line and spaces for indentation... But way worse is having no brackets at all (looking at you Python): it's clearer to have lower-level code inside some sort of "container" markers i.e. brackets (also gives more IDE functionality like color-coding hierarchically).
Indentation should always be tabs so anyone can have their own width of indentation set through their IDE, making it way more accessible to fellow colleagues!
And I also like having parameterized code over hard-coded functions: way more flexible. -
Augustiner, Tegernseer, Coffee, and at one time, White Widow.
And we don't talk about the time with the white widow.
Top Tags
Weekly Rant
View