- Win32: WaitOnAddress vs. WaitForSingleObject - 13 Updates
- Available C++ Libraries FAQ - 1 Update
- atomic<>-costs - 1 Update
| Keith Thompson <Keith.S.Thompson+u@gmail.com>: Jan 16 03:35PM -0800 Öö Tiib <ootiib@hot.ee> writes: [...] > Yes, and it is pointless to take someone with too different taste > into team. Resulting code base will look inconsistent garbage and > trying to achieve more consistency will waste precious time. At the risk of stating the obvious, it depends on whether someone with different taste is willing to be flexible. For example, I have strong opinions about brace placement and indentation (and std::), but in a work environment I set them aside and conform to coding standards and existing conventions. -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com Working, but not speaking, for Philips Healthcare void Void(void) { Void(); } /* The recursive call of the void */ |
| Bonita Montero <Bonita.Montero@gmail.com>: Jan 17 09:48AM +0100 > Yes there are no universal better. For you it is better to write ambiguous > code because of 5 characters less to type. For me it is better when such > people are not in my team. Tastes vary. As Alf correctly stated here there aren't any ambiguities here. |
| Juha Nieminen <nospam@thanks.invalid>: Jan 17 09:03AM >>> I think the code is more readable than with the std::-srpaying. >> Care to present an actual argument of why? > Because it's redundant information you need. The language is *full* of repetition and "redundant" information. How many semi-colons do you write in your source code? How many parentheses and curly braces? How many times do you write keywords like 'int', 'for' or 'return'? I don't see you complaining about the sheer amount of semicolons you need to write, and trying to get around that problem. If you use a library like libpng, do you go your way to try to avoid having to write all those 'png_' prefixes? If not, why not? What makes 'std::' so special that you religiously avoid it? > Won't read the rest of your nonsense. Of course not. Just goes to show how petulant you are. I'll take that as a tacit admission of defeat. |
| Juha Nieminen <nospam@thanks.invalid>: Jan 17 09:13AM > it was something like: > #define tcreate pthread_create > #define tjoin pthread_join To be fair, this might have more to do with trying to make code as short as possible, rather that avoiding a particular prefix. Not that making code as short as possible is any better. I think it's an interesting psychological phenomenon why so many beginner programmers, and even not-so-beginner ones, always try to make code, especially variable and function names, as short as possible. I see that kind of code quite a lot in my work, where I oftentimes need to further develop and use code made by others. This seems to be quite common with a particular kind of C programmers, who will often shorten names so much that they may become almost indecipherable and make the code harder to read (especially when many similarly named variables are being used). Like for example naming something 'evts' instead of 'events', 'err' instead of 'error', and so on. Although, POSIX (and the unix world in general) is full of this, so it's perhaps not a great mystery where they have learned this kind of coding. |
| Juha Nieminen <nospam@thanks.invalid>: Jan 17 09:21AM > with mouse in some kind of visual studio over the name then it shows > long form in tooltip? Just don't hire him ... problem solved. > Pointless to argue and to waste time. In a particular, relatively popular open source project I was involved with some years ago, which had started some time in the mid-90's, at some point in the early 2000's there was this lead developer who was absolutely obsessed about not using namespaces, and often wrote long rants about how namespaces are evil, and made (to be frank, rather stupid) arguments about how it's actually *better* to always use "using namespace" than the prefixes, how there are actually benefits to it (other than just the cosmetic "benefits"). The project used quite extensively the Boost library, so rather obviously all the source files in the project had these at the beginning: using namespace std; using namespace boost; You might already guess where this is going. Yes, indeed, as 2011 was slowly approaching and more and more compilers started implementing more and more of the upcoming C++11 standard, people started issuing bugfix reports that the project wasn't compiling because of clashing names (the most common issue was the name 'shared_ptr'). This guy's response? "Use a standard-conforming compiler!" That was his official response that he stubborningly got repeating, no matter what arguments was presented to him, all the way up to when the C++11 standard was officially published. It took a year or two before he kind of "semi-retired" from the position and the rest of the development team finally refactored the entire codebase to be C++11 compliant. |
| Bonita Montero <Bonita.Montero@gmail.com>: Jan 17 10:24AM +0100 > How many semi-colons do you write in your source code? How many > parentheses and curly braces? How many times do you write keywords > like 'int', 'for' or 'return'? That has nothing to do with this discussion. We're just talking about tastes and you're trying to dictate your taste to me. |
| "Öö Tiib" <ootiib@hot.ee>: Jan 17 04:09AM -0800 On Sunday, 17 January 2021 at 01:36:10 UTC+2, Keith Thompson wrote: > > trying to achieve more consistency will waste precious time. > At the risk of stating the obvious, it depends on whether someone with > different taste is willing to be flexible. Sure. It is normal that people follow policies that may differ with their personal views if they want to cooperate. But "Won't read the rest of your nonsense." is ending any interview. Removing, loosening or reverting whatever policies because of taste of new member is not possible so they have to bend or go. They can raise such change request but it will be most likely rejected as request of worsening. > opinions about brace placement and indentation (and std::), but in a > work environment I set them aside and conform to coding standards and > existing conventions. About white-space usage we can easily use some kind of formatting software that keeps eye on style of white space automatically (like unit test of all code files in continuous integration). We can even vote where is space, where is indentation and where not with whole team and set it. But about naming conventions and namespace usage there are no such good tools I know of. So we can only automatically validate that "using namespace" has nowhere been uttered. |
| Bonita Montero <Bonita.Montero@gmail.com>: Jan 17 01:54PM +0100 > or reverting whatever policies because of taste of new member is not > possible so they have to bend or go. They can raise such change request > but it will be most likely rejected as request of worsening. We're not a team here so there aren't policies, but just a number of individual tates. |
| Nikolaj Lazic <nlazicBEZ_OVOGA@mudrac.ffzg.hr>: Jan 17 02:27PM >> but it will be most likely rejected as request of worsening. > We're not a team here so there aren't policies, but just a number of > individual tates. Hm... but when you ask other to read your code... then you are actingr as a part of the team. This is what everybody is pointing out. |
| Bonita Montero <Bonita.Montero@gmail.com>: Jan 17 04:17PM +0100 >> individual tates. > Hm... but when you ask other to read your code... then you are actingr > as a part of the team. ... Everyone here has its own taste. And using std::-spraying isn't common. |
| "daniel...@gmail.com" <danielaparker@gmail.com>: Jan 17 08:03AM -0800 On Sunday, January 17, 2021 at 7:53:49 AM UTC-5, Bonita Montero wrote: > We're not a team here so there aren't policies Indeed. On Thursday, January 14, 2021 at 10:47:44 AM UTC-5, Alf P. Steinbach wrote: > The standard library function names are lowercase, usually using the > snake case convention with underscores as word separators, like > `duration_cast` and `high_resolution_clock`. Just so. And it's common to avoid namespace prefixes in examples and tutorials when there is no risk of confusion. Daniel |
| Nikolaj Lazic <nlazicBEZ_OVOGA@mudrac.ffzg.hr>: Jan 17 04:04PM >> Hm... but when you ask other to read your code... then you are actingr >> as a part of the team. ... > Everyone here has its own taste. And using std::-spraying isn't common. Sure... when you do things for yourself. I use i,j,k for integers and a,b,c for floats... I guess a bit of Fortran remained. :) But I do use std::. And I do use "normal" names for variables when doing something with others. Or presenting my code. As I would be asking for their time and trying to waste as little as possible. |
| Bonita Montero <Bonita.Montero@gmail.com>: Jan 17 07:31PM +0100 > And I do use "normal" names for variables when doing something with others. > Or presenting my code. As I would be asking for their time and trying to > waste as little as possible. It's impossible to satisfy or anticipate most peoples tastes. And I don't complain about such subtle style-differences but just read the code, even if it doesn't match my favourite style. |
| "Öö Tiib" <ootiib@hot.ee>: Jan 17 02:59AM -0800 On Sunday, 17 January 2021 at 01:22:23 UTC+2, Chris M. Thomasson wrote: > > Maintainer: Nikki Locke - if you wish to contact me, please use the form on the website. > Gotta love the following link! > http://www.trumphurst.com/TrumphurstRemoteControl.exe Oh it is just needed so Trump can remote control his hurst with it. |
| Bonita Montero <Bonita.Montero@gmail.com>: Jan 17 11:27AM +0100 According to this https://www.bfilipek.com/2019/08/newnew-align.html C++17 honors alignas. |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment