Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. General Programming
  3. Design and Architecture
  4. Minimize the risk that (bad) programmers call specific functions?

Minimize the risk that (bad) programmers call specific functions?

Scheduled Pinned Locked Moved Design and Architecture
algorithmsquestion
8 Posts 5 Posters 2 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • A Offline
    A Offline
    arnold_w
    wrote on last edited by
    #1

    At my company there are few programmers that are either lazy, non-quality minded, unintelligent or all of the above. I have written a driver and they have to provide a GUI on top of that driver. Normally, my driver would be very thin with no restrictions, but knowing the quality of my co-workers I have added a validation layer on top of the low-level drivers because I care about the success of my company. How would you recommend I minimize the risk that they bypass the validation layer and call the low-level functions directly? Should I encode my variables, function names and parameters, using some kind of ASCII encoding algorithm, so it's difficult to understand what the functions do? Should I name my low-level functions something like KEVIN_JEFF_AND_MARK_NEVER_CALL_THIS_FUNCTION_writeMemory(uint32_t addr, uint8_t value)? Any other ideas? I've already talked to my boss and he thinks it's too difficult to find new programmers to get rid of them.

    L J M C 5 Replies Last reply
    0
    • A arnold_w

      At my company there are few programmers that are either lazy, non-quality minded, unintelligent or all of the above. I have written a driver and they have to provide a GUI on top of that driver. Normally, my driver would be very thin with no restrictions, but knowing the quality of my co-workers I have added a validation layer on top of the low-level drivers because I care about the success of my company. How would you recommend I minimize the risk that they bypass the validation layer and call the low-level functions directly? Should I encode my variables, function names and parameters, using some kind of ASCII encoding algorithm, so it's difficult to understand what the functions do? Should I name my low-level functions something like KEVIN_JEFF_AND_MARK_NEVER_CALL_THIS_FUNCTION_writeMemory(uint32_t addr, uint8_t value)? Any other ideas? I've already talked to my boss and he thinks it's too difficult to find new programmers to get rid of them.

      L Offline
      L Offline
      Lost User
      wrote on last edited by
      #2

      You provide them with an "interface" that only exposes the methods and properties that you want them to see. Most programming languages (which you didn't specify) have "interface" patterns. [Designing C# Software With Interfaces - Simple Talk](https://www.red-gate.com/simple-talk/dotnet/net-framework/designing-c-software-with-interfaces/)

      It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it. ― Confucian Analects: Rules of Confucius about his food

      A 1 Reply Last reply
      0
      • L Lost User

        You provide them with an "interface" that only exposes the methods and properties that you want them to see. Most programming languages (which you didn't specify) have "interface" patterns. [Designing C# Software With Interfaces - Simple Talk](https://www.red-gate.com/simple-talk/dotnet/net-framework/designing-c-software-with-interfaces/)

        It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it. ― Confucian Analects: Rules of Confucius about his food

        A Offline
        A Offline
        arnold_w
        wrote on last edited by
        #3

        The programming language is C#. We don't want to use a dll because then we can't step through the code when debugging.

        L 1 Reply Last reply
        0
        • A arnold_w

          The programming language is C#. We don't want to use a dll because then we can't step through the code when debugging.

          L Offline
          L Offline
          Lost User
          wrote on last edited by
          #4

          Dll's don't preclude debugging. Use a wrapper class then. Give the "bad programmers" the wrapper that calls your dll's "open" methods, then make up a stupid name for the dll that they can't guess: StupidProgrammer.dll, for example. Though they have to add stupid dll to the project too.

          It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it. ― Confucian Analects: Rules of Confucius about his food

          1 Reply Last reply
          0
          • A arnold_w

            At my company there are few programmers that are either lazy, non-quality minded, unintelligent or all of the above. I have written a driver and they have to provide a GUI on top of that driver. Normally, my driver would be very thin with no restrictions, but knowing the quality of my co-workers I have added a validation layer on top of the low-level drivers because I care about the success of my company. How would you recommend I minimize the risk that they bypass the validation layer and call the low-level functions directly? Should I encode my variables, function names and parameters, using some kind of ASCII encoding algorithm, so it's difficult to understand what the functions do? Should I name my low-level functions something like KEVIN_JEFF_AND_MARK_NEVER_CALL_THIS_FUNCTION_writeMemory(uint32_t addr, uint8_t value)? Any other ideas? I've already talked to my boss and he thinks it's too difficult to find new programmers to get rid of them.

            J Offline
            J Offline
            joost versteegen
            wrote on last edited by
            #5

            make your functions private and call them from the validation layer

            1 Reply Last reply
            0
            • A arnold_w

              At my company there are few programmers that are either lazy, non-quality minded, unintelligent or all of the above. I have written a driver and they have to provide a GUI on top of that driver. Normally, my driver would be very thin with no restrictions, but knowing the quality of my co-workers I have added a validation layer on top of the low-level drivers because I care about the success of my company. How would you recommend I minimize the risk that they bypass the validation layer and call the low-level functions directly? Should I encode my variables, function names and parameters, using some kind of ASCII encoding algorithm, so it's difficult to understand what the functions do? Should I name my low-level functions something like KEVIN_JEFF_AND_MARK_NEVER_CALL_THIS_FUNCTION_writeMemory(uint32_t addr, uint8_t value)? Any other ideas? I've already talked to my boss and he thinks it's too difficult to find new programmers to get rid of them.

              L Offline
              L Offline
              Lost User
              wrote on last edited by
              #6

              I once had a boss and a coworker focussing on exactly that, afraid I might abuse the "Connection" object. They spent so much time on it that the project and the money-making VB6 application were both abandoned, ending the company. Your arrogance is not worth the effort. Lazy programmers are not your main concern. And please, give me the name of your company, so I can prevent asking for work there. edit-- Hi Ralph!

              Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^] "If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.

              1 Reply Last reply
              0
              • A arnold_w

                At my company there are few programmers that are either lazy, non-quality minded, unintelligent or all of the above. I have written a driver and they have to provide a GUI on top of that driver. Normally, my driver would be very thin with no restrictions, but knowing the quality of my co-workers I have added a validation layer on top of the low-level drivers because I care about the success of my company. How would you recommend I minimize the risk that they bypass the validation layer and call the low-level functions directly? Should I encode my variables, function names and parameters, using some kind of ASCII encoding algorithm, so it's difficult to understand what the functions do? Should I name my low-level functions something like KEVIN_JEFF_AND_MARK_NEVER_CALL_THIS_FUNCTION_writeMemory(uint32_t addr, uint8_t value)? Any other ideas? I've already talked to my boss and he thinks it's too difficult to find new programmers to get rid of them.

                M Offline
                M Offline
                Mycroft Holmes
                wrote on last edited by
                #7

                Change jobs, seriously if you cannot trust your co workers to do the right thing and your boss thinks it is too difficult to get competent developers then your company is doomed.

                Never underestimate the power of human stupidity - RAH I'm old. I know stuff - JSOP

                1 Reply Last reply
                0
                • A arnold_w

                  At my company there are few programmers that are either lazy, non-quality minded, unintelligent or all of the above. I have written a driver and they have to provide a GUI on top of that driver. Normally, my driver would be very thin with no restrictions, but knowing the quality of my co-workers I have added a validation layer on top of the low-level drivers because I care about the success of my company. How would you recommend I minimize the risk that they bypass the validation layer and call the low-level functions directly? Should I encode my variables, function names and parameters, using some kind of ASCII encoding algorithm, so it's difficult to understand what the functions do? Should I name my low-level functions something like KEVIN_JEFF_AND_MARK_NEVER_CALL_THIS_FUNCTION_writeMemory(uint32_t addr, uint8_t value)? Any other ideas? I've already talked to my boss and he thinks it's too difficult to find new programmers to get rid of them.

                  C Offline
                  C Offline
                  cjb110
                  wrote on last edited by
                  #8

                  Don't expose the functions as public then? They should only be seeing the public interfaces you want them to see. Also start to employ more defensive programming with in those functions, validate all the incoming parameters, and fail early and often if they're not within the spec. If its function order then maybe you could add a audit type layer, so you can ensure function x is called after function y. Generally though, why would they call a function they don't need? If they're calling it from the GUI then surely there's a spec that says that's what the GUI needs to do? And your driver should be providing a safe method for that?

                  1 Reply Last reply
                  0
                  Reply
                  • Reply as topic
                  Log in to reply
                  • Oldest to Newest
                  • Newest to Oldest
                  • Most Votes


                  • Login

                  • Don't have an account? Register

                  • Login or register to search.
                  • First post
                    Last post
                  0
                  • Categories
                  • Recent
                  • Tags
                  • Popular
                  • World
                  • Users
                  • Groups