{"action":"opened","issue":{"url":"https://api.github.com/repos/ComputationalRadiationPhysics/picongpu/issues/766","labels_url":"https://api.github.com/repos/ComputationalRadiationPhysics/picongpu/issues/766/labels{/name}","comments_url":"https://api.github.com/repos/ComputationalRadiationPhysics/picongpu/issues/766/comments","events_url":"https://api.github.com/repos/ComputationalRadiationPhysics/picongpu/issues/766/events","html_url":"https://github.com/ComputationalRadiationPhysics/picongpu/issues/766","id":63209232,"number":766,"title":"Restrict scope of coding guideline \"put spaces around division operator \"","user":{"login":"BeyondEspresso","id":5319938,"avatar_url":"https://avatars.githubusercontent.com/u/5319938?v=3","gravatar_id":"","url":"https://api.github.com/users/BeyondEspresso","html_url":"https://github.com/BeyondEspresso","followers_url":"https://api.github.com/users/BeyondEspresso/followers","following_url":"https://api.github.com/users/BeyondEspresso/following{/other_user}","gists_url":"https://api.github.com/users/BeyondEspresso/gists{/gist_id}","starred_url":"https://api.github.com/users/BeyondEspresso/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/BeyondEspresso/subscriptions","organizations_url":"https://api.github.com/users/BeyondEspresso/orgs","repos_url":"https://api.github.com/users/BeyondEspresso/repos","events_url":"https://api.github.com/users/BeyondEspresso/events{/privacy}","received_events_url":"https://api.github.com/users/BeyondEspresso/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":0,"created_at":"2015-03-20T11:02:59Z","updated_at":"2015-03-20T11:02:59Z","closed_at":null,"body":"1.) The justification of this codeguide is readability, which in the case of\r\n```\r\n( long bracketed expression )  /  ( long bracketed expression )\r\n```\r\nmakes a lot of sense.\r\n\r\n2.) However, spacings around divisions can suggest another order of precedence.\r\n```\r\n num1  /  num2*num3*num3\r\n```\r\nlooks like\r\n```\r\n num1  / (num2*num3*num3)\r\n```\r\nbut really is equivalent to\r\n```\r\n(num1  /  num2)*num3*num3\r\n```\r\nHence this spacing rule, which is supposed to ease readability can lead to misunderstandings of the code. This is the main argument.\r\n\r\n3.) Furthermore, as in text ligatures, short expressions such as `PI/2` or `1/E^2` are read as one contextual unit. Hence, the variant with spacings `PI  /  2` -- especially when other operators are in the same math expression -- is actually tripping the reading flow.\r\n\r\n4.) Also, division operators are more frequent than assignment operators. With our 100 chars per line restriction long, but structured mathematical expressions can extend beyond the limit and one has to add a new line just because of a few spaces, which in turn again reduces readability. This argument is the weakest, but does occur regularly in real code and is more a symptom of the maximum line length allowed vs. the amount of whitespace enforced by coding guidelines.\r\n\r\nConclusion: In contrast to the \"spacings around assignment operator rule\", this rule is often more trouble than it is worth. I propose to either make the \"spacings around division operator rule\" optional or restrict it to use case 1.) ."}}