Artöm
It happens not often though
András
The naming is making it less readable, auto doesn't improve that
But when I posted that example here, you havent read the name fully, and decided, that you have already read what you have to
Javi
Nope, becouse I know what auto means, becouse we have good naming
Yes. By looking at auto var=next_step(); you know that it is returning a shared pointer? Amazing 😁
Francisco
Nope, becouse I know what auto means, becouse we have good naming
Also, good variable naming should be enough to understand what a variable does
András
Oh, you asked me, which name I use for a function. Right now, I am working with function shared_ptr<fucking_rabbit_very_fast_random_move_class> next_step()
this name is about 1.5 lines on my screen(in tg). If I add constructor, that will be 5-6 lines. and You havent to navigate on the screen while reading the code
Javi
It happens not often though
Yes, sometimes is does, sometimes it doesn't. Problem is, you never know when it will be relevant
Javi
Long names are as unreadable as meaningless names
András
Long names are as unreadable as meaningless names
I read only first word, becouse there is no other fucking_*😂
Javi
Yeah, I know what next_step() returns
Yes, and your colleagues using your code too. And you all remember that 6 months ago somebody thought of changing the return type. As I said, I envy your working environment
Javi
I read only first word, becouse there is no other fucking_*😂
If you have naming that takes more than one line, you have a naming problem, regardless of what you read
Javi
If tests don't pass, you shouldn't have changed anything to begin with
We mentioned that before. Tests don't cover everything
Javi
If they exist at all
Javi
If you wrote the code
Javi
etc
Francisco
We mentioned that before. Tests don't cover everything
They should cover almost everything that can fail
Francisco
If they exist at all
If they don't, you know what to do
Javi
They should cover almost everything that can fail
You said it. They should. They normally don't
Javi
It seems that there are many people working here in isolation
Francisco
You said it. They should. They normally don't
In serious projects, tests are always a must
Javi
And tests never cover 100% of the cases
Francisco
And tests never cover 100% of the cases
And? Good tests cover almost everything
András
And tests never cover 100% of the cases
But, you try to cover everything
Francisco
You would be surprised
I'm surprised when projects don't have them
Javi
But, you try to cover everything
Try is different from achieving
Javi
I'm surprised when projects don't have them
Maybe I have more experience, because I'm not
Ludovic 'Archivist'
I would say good tests have a coverage of all lines of code AND all the bug cases you already resolved or have been able to reproduce
Ludovic 'Archivist'
And the special cases you may have listed in specifications
Francisco
Maybe I have more experience, because I'm not
If those projects where the didn't test are meant to be serious, then you should question the professionality of that team
Javi
Every single line?
Javi
Which company is that?
Ludovic 'Archivist'
Every single line?
Every line of code that could reach production
Ludovic 'Archivist'
Well, I had to work a lot to make those tests happen
Francisco
TDD is a fairly recent trend
As it should be. I blame myself when I'm finished writing some code and then have to program all the test when I should have done it to begin with
Javi
Well, I had to work a lot to make those tests happen
And the code won't be long, because I have serious doubts that it can be achieved in a code that is several tens or even hundreds of thousands of lines
Javi
You would drive the company bankrupt before you can release anything
Javi
So you have like 20 to 100 more lines of test code than production code
Javi
Or 1000 more lines
Javi
Your company has deep pockets
Ludovic 'Archivist'
Ludovic 'Archivist'
I don't aim for full unit test, I aim for every line covered and every bug case covered
Ludovic 'Archivist'
Which mean functional tests are possible (and encouraged)
Javi
No, about 50% of prod code as test code
Then sorry, but you aren't testing every line. You can't just have an average of 2 lines of test per production code
Javi
It just doesn't add up
Javi
I don't aim for full unit test, I aim for every line covered and every bug case covered
I'm sorry, but you don't achieve that with two lines of test code
Ludovic 'Archivist'
I'm sorry, but you don't achieve that with two lines of test code
You do not if you aim for unit testing. Functional tests are another beast
Ludovic 'Archivist'
If you call a high level function it calls quite a bit of the low level features
Ludovic 'Archivist'
Also, actually writing code is in my opinion 20% of the job
Ludovic 'Archivist'
80% of my job is making correct specifications
Ludovic 'Archivist'
Months of coding save days of planning
Javi
That's not "covering every line". You have no idea whether a class works or not. Two errors may make a right output
Ludovic 'Archivist'
That's not "covering every line". You have no idea whether a class works or not. Two errors may make a right output
I know I explore every path of every function, error cases included, as well as reported bug cases and performance sensitive parts
Ludovic 'Archivist'
When I say every line of code, it is every line of executable code as per LLVM coverage tools, which includes every branch and exception cases
Ludovic 'Archivist'
You want a thing that is actually not that well tested here? Concensus related code. That is nasty to test and debug
Ludovic 'Archivist'
Those are actually test cases I don't know how to handle. I can run through every line of it and it will still never be properly tested
Ludovic 'Archivist'
(I work in database development BTW)
Javi
I know I explore every path of every function, error cases included, as well as reported bug cases and performance sensitive parts
No you don't explore every path of every function. That's just only possible with the simplest functions. And functional programming don't go to the level of testing functions/methods. That's unit testing
Javi
Functional testing =/= Functional programming It means testing every feature of the software (functionalities)
I know it. But you functional testing doesn't test every path (meaning every possible input and out) of every function. That is just impossible, specially if the input is some user input. It actually doesn't test functions, but as you say, a functionality, which is way different. If you use a library, it may be broken, but just happens to work fine with your program, because it doesn't use the broken feature.
Ludovic 'Archivist'
Oh, also, for your information, SQLite is renowned for having a coverage of 100% too (not my work tho, but th1 th2 and th3 are pretty sick tests)
Javi
What you do is a long way from "testing every line"
Ludovic 'Archivist'
I have yet to add afz to my workflow
Ludovic 'Archivist'
But I run through every line and every branch, never said for every input
Javi
Oh, also, for your information, SQLite is renowned for having a coverage of 100% too (not my work tho, but th1 th2 and th3 are pretty sick tests)
https://sqlite.org/testing.html And they have 662 times as much test code and test scripts, not twice as you
Ludovic 'Archivist'
I run for some expected to work inputs and some expected to fail inputs for every function tho