Code review and other bad practices

Does anyone in this thread even have a job? Code reviews serve a plethora of different purpose, improved code quality is not even the main argument. It's about sharing knowledge within the team. I work in a team of 12 developers, and not a single line of code gets pushed in to the repository without my knowledge.

Writing tests to me is either to annoying to think about doing correctly so I don't do it all or I go into this mode after a while where every test case I'm just mindlessly phoning it in not thinking at all about what I'm actually testing.

I mean ya you can add a bug in a test case when it pops up but to me a lot of the time its kind of pointless.

I've been working over 15 years. If you personally need to review every single commit then either your team is absolute shit or you have incurable autism.

You sound delightful to work for.

I'm working with lazy ass Russians, half the time they don't even read the whole specification.

I'm not their boss or anything, I just want to make sure that the software I am working on meets a standard.

Good idea, right? Like Communism - absolutely good idea. But implementation of Communism delegates so many right to some people that they begin to build something very different from initial idea :) The same with CR. This is real example in my life:
one very big (US) company. I made some feature. Feature includes refactoring (there were a lot of signal handlers with a lot of bussiness logic in handlers, which is wrong, sure). So, I made handler to put message to some queue and worker which executes the messages. Team lead likes own (wrong handlers) and no way to convince him that it's wrong to have so big and weight signal handlers. Review process leads to backward refactoring (with some strange hangup, possible to those handlers). A long review process, several reviewers, a lot of tests, a lot of meetings, quoting of standards, guideline - no effect! Wrong solution was submitted. So, my recap: sharing of code, code review, other similar modern corporate standards leads to problems: in teams, in code, in quality. And no such shit in old-days companies. What is the real reason to have such practices? Code review is the same shit as numerous meetings: a lot of people pretend that they work. Code review is such example leads to concreat wrong code submitting: because ARGUMENTS IN CODE REVIEW ARE ALWAYS (!) PERSONAL AMBITIONS. Absolutely like Communism - good idea, shit result.

+1 this

The quality of the code-review depends entirely on the qualities of the reviewer. If the reviewer has a shallow understanding of development, you're going to get shallow code-reviews.

If your reviewer is a toptier architect, you'll learn from the review.

But yeah, most reviewers are pedantic;
Female senior X: "[fieldname] should be [casetype]"
Me: "but these [fieldnames] map unto opengraph names, and now i have to rename everything"

my review;
Me : "why are you pulling in 200 mb badly maintained dependencies, just to get a list of ISO country codes?"
Russian developer Y : "It werks. Fuck off, X is my boss not u"

you must say: "What?!?! Let's go to your boss, mazafaka" :) Joke, I don't know traditions in your company but good is to discuss such approaches in big group, so there are another devs which will support you -- for example.

---
Here sounds another interesting point: review is place of sharing knowledge. Unfortunately, it's not true too. I never meet situation when somebody says: "Wow!!! So cool and smart code!" but always: "I don't understand this code! It must be simplified or rewritten totally!". And arguments like "maan! This is language standard! Read this and that and you will understand this code" have not effects. "I don't understand" = "bad" that's all. But this leads to skill's fall of team - to be equal to the worst team member.

Problem with CR that always you listen "seems", "I don't like", "I prefer", "there is another way", etc. It's super-super subjective and personal assessment.

>code lacks abstraction so badly that unit tests are implementation dependent
>interface is so incoherent that it is subject to constant change

Attached: 1526151484737.jpg (480x480, 34K)

t. Neet

>Communism - absolutely good idea
Nice meme. Everything about it is trash.

The fact that people still resort to comparing things to nazis and communism just shows how little we developed as a political society.

Attached: 1526211391416.jpg (559x1024, 59K)

I like code reviews. It makes me feel more comfortable pushing my code to production. If someone else has looked at it, they may catch some bug that I missed, and at the very least I'm not the sole person to blame if it blows up. Plus I like being able to enforce strict guidelines on my coworkers. Sometimes people have lazy days or they're new and don't know the standards of my company. I also find bugs sometimes.

What I'm getting from this thread is that if Jow Forums ran a software company there would be
- no unit testing
- no code review
- no refactoring

>it just werks

I run several open source projects. I reject 25% of all PRs I get as unsalvageable (poor code quality, bad architecture and a bad idea) and rewrite another 25% myself because it takes less time than fixing the PR. If I didn't, my users would be fucked. I am continually surprised by how little effort and thought people with professional-looking photo avatars and a profile that says they're located in the Silicon Valley put into their code. In fact, I've come to expect better code quality from anime avatars.

>but testing - is very important and it's correct and unbiased criteria that code is fine.

So instead of the quality of your code or CR, you're now relying on the quality of your test code. I started reading a book on TDD and while the author raved about it, I couldn't help but think that all this is doing is shifting the burden to another area. It would be super easy to write a test that you think checks the right thing but it doesn't and passes. How would you know unless well, you or someone else looked at your code? In other words, you already know what you're doing. Testing is nice, TDD is a waste of time that exists solely for developers to jack themselves off over menial tasks.

see

Anime avatar means that they don't care about how they are perceived by others and do what they truly like doing, watching anime and programming.

To make it even more retarded, some fields have code review requirements stipulated by laws.

You'd think that on GitHub out of all place people who care how they are perceived by others would care about what their code says about them.

Of course you can write shitty tests. TDD is just a discipline where you get the tests for free.

Jow Forums has already worked on many software projects. Here's how we do things.

>no unit testing
Can't be any unit tests if there are no units.
>no code review
There's no code to review.
>no refactoring
Write zero times read zero times.

I'll do the logo.

Attached: atomwaffendepravity.jpg (913x1200, 186K)

I've come to the conclusion that most people use their github profile as an addition to their linkedin profile. An HR person can verify if you have any commits to larger projects, they won't know anything about the code quality though.

The people whose opinions they care about can't code either. It's "Xir typed stuff in a text editor that looks like hacker code. See girls (male) can kode too!"

>review someone's code
>catch a spelling error that would have broken one of his APIs
Yay I'm helping~

Attached: 1524899898.png (268x330, 39K)

Imagine if instead of FizzBuzz and inverting binary trees interviews were like "Okay, let's talk about your commits".

I worked at a company with code reviews, and now at a non-software company without.

At the company without code reviews I walk into the other office to ask someone something, and see that
>Someone is using XEmacs (no I didn't typo, literally the obsolete fork from the 1980s).
>Someone is wasting hours a week for literally years because they never realised you could just automate something with a simple bash script
>Someone else is wasting literally hours a day because they never got introduced to a code editor more functional than gedit and search and replace blows their mind.
>Someone doesn't know what classes or inheritance are and wrote a large complicated program entirely with globals and functions.
>Someone wrote an entire processing toolbox in python 2.7 because they didn't know or care that python 3 was a thing and will "port it later".

Without code reviews noone learns anything because most people are lazy and use the first thing that works. You need code reviews to share knowledge and to hire a lead developer that actually gives a shit about learning new things and can tell people they're morons for using an obsolete code editor from the 1980s.

My favorite weed filter interview question is "Which git commands do you know?"

Some people honestly admit they have no clue, others are so desperatele that they give me answers like "Oh, command line? Sure I know about it, you can use cd to change directories."

>Oh, command line? Sure I know about it, you can use cd to change directories.
Oh wow. Where do you get programmers who don't know Git OR the command line? Have they never left an IDE in their lives or are they just lying about being able to program at all?

Most of them are girls or refugees, HR keeps inviting them to interviews to increase our diversity.

>refugees
Not sure if you're memeing right now, but if you aren't, you have my sympathies, user.

It's another dark side of modern IT companies traditions (similar to CR). Developers become geeks instead of good specialists: they know how to solve tricky interview tasks, how to speak about different buzzwords, what T-shirts to have on interview, they like to look like math/computer genius, but they can not create beauty and good code. Sure, there are a lot of good specialists too, but... One of my 1st boss was old-school man (you know, with "tortoise" glasses, jacket and pantaloons) and I read his books, some of them were about comp. graphics, another one about queue servicing, very old books, mostly without any code but with a lot of integrals, different long math formulas and I found many pencil notes with corrections in those formulas! He made different interesting and complex software on vxWorks, QNX, MS-DOS and I know that my modern co-workers absolutely can't write similar software, but they are super geek and super modern. And we have a lot of meetings, code-reviews and other agile...

I have tons of cases, when I and others were refactoring for nothing:
>write using style X
>write using object/class/functional paradigmatic
yes on this team are 3 fucking different groups
>you have written flavour not flavor
out client is usa based so don't use british spelling.

>Critical bug across few files
>important PR
No one gives a fuck or checkout the brach and run in localy.

And for naming, conversions, basic quality just use linting. Testing is nice, but don't fucking make tons of tests that are testing exacly nothing or shit like 1+2=3, but in the fog of abstraction.

Attached: maxresdefault.jpg (1280x720, 206K)

I hate the Git. It looks very complex and involves a lot of abstractions and details. For example, there are versions control software for CAD/CAMs like Unigraphics. Sure, it must be super-complex, but... it's not true - because it is using by designers. And when I imagine that such soft may be written by Linus... oh my God, it will be super complex super shit.

how the hell do XEmacs guy and gedditor even coexist?

Attached: 1522473629212.jpg (612x612, 91K)

someone post the image of some rm command missing a / so it deleted all of /usr

I'd probably say "None, I just configure Emacs' vc-mode".

please dont I get anxiety attacks every time I see it

Attached: 1527861330568.jpg (1280x720, 71K)

please be joking

Attached: 1526511604995.jpg (677x799, 144K)

there are a different testing style, you know: for example you can write tests which will drive you (TDD). But you can write tests which will fixate some bug fix (test fails when no fix and a pass means that no regressions, bug is not repeating). Also customer may give you some acceptance tests which fixate some phase of development process. Also often you can get requirement for performance tests. But no way for complex and multi-component (heterogeneous) system maintenance without integration tests. So tests are your guard from changeable world and customers sometimes ;)

>>Someone else is wasting literally hours a day because they never got introduced to a code editor more functional than gedit and search and replace blows their mind.
Show him Geany. I've done it before.
>Someone doesn't know what classes or inheritance are and wrote a large complicated program entirely with globals and functions
Honestly, programmers who learned to use inheritance for everything in pre-98 C++ are worse. Teach a procedural programmer to not use globals and reduce mutation, and you'll have a functional programmer.

fuck code review, amirite??

Attached: unnamed.jpg (900x900, 94K)

if somebody is going to fuck me over some day it is going to be the devs of the software I use

>I get anxiety attacks every time I see it
That's moe.

> XEmacs
2018.
Sounds very cool. Btw, real strong old school programmer uses usually super old Emacs distribution with its old configuration and scripts, old WM (something like TWM or Window Maker). XEmacs sounds very warm too

Don't worry. Usually all relevant distros keep an eye on their official repos. They aren't run by valve, hyuk

Attached: 1524271016001.jpg (850x438, 410K)

OK, ok :) such kind of bugs make sense to be CR'ed

>tfw I always fall for the depressed ones

I can understand people using old WMs as long as they can. I mean, when I'm in my 60s I don't want to be told to reorganize my entire workflow because some people memed a new paradigm for user interfaces into existence.

>Teach a procedural programmer to not use globals and reduce mutation
might as well try to teach pajeet not to shit on the street.

>tfw the transition from Fortran77 to Lisp is more intuitive than to any Perl^H^H^H^HC derivative

why not go to fortran 90 and beyond

Problem with PErl for most developers is that they are oriented to computer constructs but Perl was designed by linguist. So Perl iintroduces some constructions from human languages. Do you see Perl6?

I use a GUI.
:P

JetBrains and Visual Studio UI for vers. contr. looks really good and useful. Also Magit is good (but I don't know is it GUI?). But I never tried UI in Visual Studio Code. What exact UI do you use?

It is funny, I have worked for three different companies, and every one of them made a big deal about testing during the interview process. None of the projects I worked on had any tests whatsoever and we were never given the time to write new ones for the functionality we built. Testing is like flossing or working out. Everyone knows they should, but ain't no one got time for that shit.

This is not about Perl per se, it is about the C family. From my perspective C is a very perverse language, since it took everything beautiful fortran had and made it ugly.
F95 was better in many regards but started to introduce various cancers from other langs; atrocities such as pointers, half-baked abstractions, and outright silly changes like abolishing structured code and flexible continuation makers with abhorrent, unreadable syn&
&tax.

>how the hell do XEmacs guy and gedditor even coexist?
They don't speak to each other.
There are no code reviews or pair programming. Everyone is silo'd and has one task that noone else touches.

Honestly, that sounds comfy (if it works).

Maybe, this means that there is super good responsibility differentiation/interfaces/architecture/components differentiation

I kind of like the fortran pointers for implementing some data structures in conjunction with user-defined types, though I faintly remember other OOP-features being pretty tacky.
the pointers do not seem too obscene to me when compared to ones like those from C

Just "Github Desktop"
I was using it with code hosted on gitgud ans it worked fine.

It's comfy if you've got a good project and free reign to do what you want.

It's absolute hell if you've got a bad legacy project. I've got one of each but now the shit legacy one is top priority.

It also leads to weird shit like the examples I gave happening when you see your coworkers doing retarded and inefficient shit.
Imagine the worst junior developer you've worked with, the one who couldn't grasp the most simple concepts and copy pasted stack overflow code without understanding it. Now imagine him being given free reign and little oversight.

sounds like Cobol project... Nop.
COBOL!

Do any of you guys do fuzzing?

There's lots of interspersed UK and US English in the Linux kernel. A ton of misspellings, too.

If you have the time to code new tests that's good, but they don't catch everything and that's what people paid to find bugs do. So they're nice to catch something humongously flawed with it but other than that they're not going to be worth the effort for some things.
And code reviews are good in theory. Sometimes they can help especially with finding other bugs that might be in other areas, but most of the time people usually just click accept because it works or they'll comment dumb shit like "fix uneven comment spacing",

Attached: Df1xhZVV4AArCwi.jpglarge.jpg (769x1078, 112K)

I'd just be like I like commit and push. But I use tortoise git because it's much faster than doing it command line and it's easier too

Often we overestimate style. Especially own style. This is reflected in CRs. When I have for the first time seen Quake 1 code, I thing: I know this style, but I'm using another one. Whether he has chance to pass an CR? But yes - "it works". And not only works, but brought good money :)

that just means a company has a terrible social infrastructure.

Shut the fuck up already you non-white

whaz ur problem, my little white bro? :))

Holy shit, this thread is the actual reason IT jobs are shit. Working with colleagues who can't fucking review your code or write tests? If all of you Chad coders left IT we would be happy.

I require at least one review (mine) on all pull requests into our company code base. Mainly because my coworkers write the shittiest code imaginable.

Attached: 1529965333565.png (900x729, 129K)