{"action":"created","issue":{"url":"https://api.github.com/repos/isocpp/CppCoreGuidelines/issues/302","labels_url":"https://api.github.com/repos/isocpp/CppCoreGuidelines/issues/302/labels{/name}","comments_url":"https://api.github.com/repos/isocpp/CppCoreGuidelines/issues/302/comments","events_url":"https://api.github.com/repos/isocpp/CppCoreGuidelines/issues/302/events","html_url":"https://github.com/isocpp/CppCoreGuidelines/issues/302","id":110200477,"number":302,"title":"C.134 - Ensure all data members have the same access level - Does this deserve to be here?","user":{"login":"khatharr","id":11417920,"avatar_url":"https://avatars.githubusercontent.com/u/11417920?v=3","gravatar_id":"","url":"https://api.github.com/users/khatharr","html_url":"https://github.com/khatharr","followers_url":"https://api.github.com/users/khatharr/followers","following_url":"https://api.github.com/users/khatharr/following{/other_user}","gists_url":"https://api.github.com/users/khatharr/gists{/gist_id}","starred_url":"https://api.github.com/users/khatharr/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/khatharr/subscriptions","organizations_url":"https://api.github.com/users/khatharr/orgs","repos_url":"https://api.github.com/users/khatharr/repos","events_url":"https://api.github.com/users/khatharr/events{/privacy}","received_events_url":"https://api.github.com/users/khatharr/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/isocpp/CppCoreGuidelines/labels/resolved","name":"resolved","color":"009800"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":15,"created_at":"2015-10-07T10:59:20Z","updated_at":"2015-10-24T06:19:20Z","closed_at":null,"body":"You know, I understand the reasoning behind this, but in my own practice it's just pointless 99% of the time and I end up undoing in those cases because I know very well that no one is ever going to inherit from the class in question. Sometimes a public member is a public member and I don't need to hide that behind annoying accessors/mutators. If trivial Java-esque things like this get put into the standard then I'm just going to disable the whole flagging/warning mechanism, and based on the hubbub I'm hearing from other people reading these right now, I know I'm not the only one who feels that way.\r\n\r\nI want to be notified about the tools offered by C++ for making things safer and more efficient, especially by avoiding dangerous legacy stuff. I don't want to know about someone's philosophical preferences, regardless of how awesome and correct they may be.\r\n\r\nNot everyone works in a production environment and not all code needs to be designed to rigorous production standards. If the tool is simply a nag then people are going to shut it off. Please use it for things that count.\r\n"},"comment":{"url":"https://api.github.com/repos/isocpp/CppCoreGuidelines/issues/comments/150762207","html_url":"https://github.com/isocpp/CppCoreGuidelines/issues/302#issuecomment-150762207","issue_url":"https://api.github.com/repos/isocpp/CppCoreGuidelines/issues/302","id":150762207,"user":{"login":"khatharr","id":11417920,"avatar_url":"https://avatars.githubusercontent.com/u/11417920?v=3","gravatar_id":"","url":"https://api.github.com/users/khatharr","html_url":"https://github.com/khatharr","followers_url":"https://api.github.com/users/khatharr/followers","following_url":"https://api.github.com/users/khatharr/following{/other_user}","gists_url":"https://api.github.com/users/khatharr/gists{/gist_id}","starred_url":"https://api.github.com/users/khatharr/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/khatharr/subscriptions","organizations_url":"https://api.github.com/users/khatharr/orgs","repos_url":"https://api.github.com/users/khatharr/repos","events_url":"https://api.github.com/users/khatharr/events{/privacy}","received_events_url":"https://api.github.com/users/khatharr/received_events","type":"User","site_admin":false},"created_at":"2015-10-24T06:19:20Z","updated_at":"2015-10-24T06:19:20Z","body":"There's no *objective* need to demand that other people conform to externally dictated design practices either.\r\n\r\nI agree with C.131 for my work and find it mildly amusing that it's present alongside this. I'm not really interested in a 30 page debate about which one to use though. This is more of an issue about whether or not I'm going to have to write a bunch of suppression statements into my code in order to make the compiler not scream at me every time I compile. If it's fully configurable then that would be fine (especially if there's a way to add things to it for shop rules, etc), but the understanding that I have - and do correct me if I'm wrong here - is that this thing is going to just jump up and start complaining about things like this regardless of whether I agree with them or not.\r\n\r\nI accepted and started using RAII when I encountered it because I thought about it and saw that it makes sense. When I was initially presented with the mixed access prohibition (a while before that) I started using that as well, but over time I realized that it wasn't helping anything and just had me writing trivial accessors when I didn't want or need them. I considered the issue, measured it against my work, and made a decision. I don't need outsiders arguing with me about it via the flipping compiler. (We have forums for petty arguments. We don't need to weaponize.) When these kinds of guidelines exist in books, references, and similar resources then they're advice. When they invade my actual work-space then they're obnoxious dictates.\r\n\r\nAnyway, when I referred to 'attributes' (yes, I meant 'properties') I was considering that there are shortcuts for trivial properties in some other languages, like {get; set;} or attr_accessor. Again, it wouldn't be trivial to do this in C++ because we handle our interfaces differently, but it struck me as being a potential middle ground."}}