Ed, não sei dizer se existe algum problema (embora eu ache que não).

Na verdade, eu sempre utilizo as macros assim, pois fica mais fácil de fazer manutenção. Eu prefiro criar pequenas subs ou funções do que criar blocos. Principalmente quando estou trabalhando com eventos, pois é mais fácil e rápido desativar a chamada de uma sub do que desativar todo um bloco.

Além disso, facilita pra aproveitar subs já escritas (que é o projeto que o Fernando está fazendo no outro tópico).

Porém, vc deve pensar em uma forma de se organizar com elas. Se tiver muitas subs, vc pode "se perder", rs (embora tenha a seleção de subs no VBE)

Primeiramente, eu sei que cada módulo tem um limite de linhas (ou de caracteres), mas não sei qual é. Por isso é bom organizar bem os teus módulos.

Segundo: eu prefro criar funções do que subs, apenas pra evitar ficar criando variáveis públicas ou globais.

Terceiro, exige que vc se padronize em relação a nomes, especialmente no seu caso. Como vc gosta de criar variáveis curtas (o que vc sabe que não é uma boa ideia, rs), ao fazer varias subs, a tendência é que vc vá para a prática mais aconselhada, que é a de criar variáveis com nomes mais longos e bem detalhados.

Abs

ola gilmar

Em ralação ao números de linhas é bem grande eu quase cheguei perto, agora vai diminuir bastante.

sobre Subs e função Byref tbm evita que se use variáveis publicas,
E funções tem o inconveniente de não executar comandos , e realmente para o meu propósito não funciona muito bem

Terceiro, exige que vc se padronize em relação a nomes,

, realmente exige que use nomes longos para as variáveis de byref e byval, para se indicar a função das variáveis, e posição delas
isso me atrapalhou no inicio, mas...
mas já superei e...
Redefino as variáveis no inicio do sub .

Não é que eu goste de usar nomes curtos,
meu estilo de raciocínio pede isso, "maluquice né"
eu estava fazendo um simples contador para testar a redefinição, limites e definição da regularidade de desmembramento de setores.
me perdi no meio, e acabei refazendo.

 ...
   For lx = lix To lfx
        Do: If nx > ctx Or nx < n1 Then VL = VL * -1: nx = (nx + VL) + VL
           colunO(lx, Cx) = nx
            nx = nx + VL: Cx = Cx + DCx
        Loop Until Cx < cix Or Cx > lfx...

Sobre variáveis publicas,
infelizmente ainda não pensei em um modo de elimina-las
principalmente as arrays de transporte.

Sub Copia_SetorO(ByVal SetorOrigem As Variant, Optional Nome_Aba_do_Setor_de_Origem As String)
    Call SetorN(SetorOrigem, Nome_Aba_do_Setor_de_Origem)
    ColunO = Sheets(nP).Range(Ti & Li, Fc & Lf).Value2
    CqO = Cq
End Sub
--------------------------------------------------------------------------------------------

Sub Copia_SetorD(ByVal SetorOrigem As Variant, Optional Nome_Aba_do_Setor_de_Origem As String)
    Call SetorN(SetorOrigem, Nome_Aba_do_Setor_de_Origem)
    ColunD = Sheets(nP).Range(Ti & Li, Fc & Lf).Value2
    CqD = Cq
End Sub
---------------------------------------------------------------------------------

Sub Colar_Setor(ByVal SetorDestino As Variant, ByRef NomeArray As Variant, Optional Linha_inicial As Long)
    If Limit = 1 Then GoTo Saida
    Dim Qc As Long
    Qc = UBound(NomeArray, 2) - 4
    Call SetorN(SetorDestino)
    If Cq <> (Qc) Then
        Call ColunasN(Qc)
        Call SetorN(SetorDestino)
    End If
    If Linha_inicial > 0 Then Lt = UBound(NomeArray, 1): Li = Linha_inicial: Lf = Linha_inicial + Lt - 1
    Range(Ti & Li, Fc & Lf).Value2 = NomeArray
Saida:
End Sub
-------------------------------------------------------------------------------------------


'-----------( Troca posição Setor  Outro Setor )---****
Sub troca_setor(ByVal Setor1 As Variant, ByVal Setor2 As Variant)
    If Limit = 1 Then GoTo Saida
    Call Copia_SetorO(Setor1)
    Call Copia_SetorD(Setor2)
    Call Colar_Setor(Setor2, ColunO)
    Call Colar_Setor(Setor1, ColunD)
Saida:
End Sub

mas consegui diminuir
talvez na sequencia consiga pensar num modo

eu tenho umas variáveis que indica as colunas, linhas e Plan de origem de origem Ti, Ci, Cf,...
nessas eu pensei em usar o Type e a macro de setor como função

Mas pelo que entendi do type junto de função, eu teria que redefini-las a cada sub
e não poderia usa-las em cascata nas macros "ou eu não entendi"

Bem ainda estou redefinindo a base, talvez apareça uma ideia nova...

Se tiver muitas subs, vc pode "se perder", rs (embora tenha a seleção de subs no VBE)

eu separo em módulos diferentes separados por função da macro "pelo menos tento"

Como assim seleção de sub?

....
Bem conforme for aprendendo eu melhoro...
vou ter que refazer algumas macro pq esqueci de adicionar a opção de Colar e Pegar de outras Pastas de Trabalho...

Ps. vc´s devem me achar maluco com esse projeto sem pé nem cabeça né, ainda mais se falando que eu não trabalho com excel.

Att e desculpe pelo livro de historia monótona.

Falando de tamanho dos nomes, eu sou meio preguiçoso pra digitar, então prefir nomes curtos. Porém, pra mim, o tamanho do nome cresce conforme cresce o projeto. em códigos curtos uso bastante "i", "j", "UL", pois é fácil identficar o que essas variáveis fazem, e chance de cometer um erro de digitação é pequena. Já em códigos maiores, é importante usar o "option explicit" e dar os devidos nomes "contador", "última linha" etc. E conforme vai crescendo, vc já vai criando padrões, identificando o tipo de variável como "ws_origem" (ws indicando worksheet), ou "arr_telefone" (arr para array).

Essa de "selecão de subs" provavelmente vc ja saiba. no VBE, acima do local onde se escrevem os códigos, tem 2 menus drop-down. (Geralmente a gente escolhe eventos por ali, mas vc tb pode ir ali e escolher o nome da sub para a qual quer ir, sem ter que ficar rolando as linhas no braço). Ajuda bastante quando vc escreve várias subs no mesmo módulo.

Ah, e sobre as variáveis públicas, evitá-las, faz parte das "boas práticas de programação". Cada pessoa ou grupo define suas próprias práticas. Eu já vi casos como dizer que "goto só se usa uma vez no código e somente para tratamento de erro", e também já ouvi falar que "on error resume next" não se deve usar nunca.

Porém, eu já me deparei com casos onde um "goto" ou um "resume next" simplificaram um código que já era simples mesmo. Portanto, eu penso que, se o comando existe, em algum lugar, de alguma forma ele deve ser útil. O mesmo vale para as variáveis públicas. É bom evitar porque cria a chance de vc se perder no código e acabar trabalhando com as variáveis com um valor que não era o esperado. Até porque, se as variáveis são públicas, acho que não convém ficar limpando os valores delas.

ah, sobre o type.

Eu li um pouco a respeito, assim como li um pouco sobre módulos de classe, mas nunca usei de fato. Até queria encontrar um material bom sobre modlos de classe com exemplos para aprender melhor (mas não achei).

Eita, que divergência,

eu já sou o contrario em macros maiores eu diminuo o tamanho dos nomes das variaveis.
mas não é preguiça de escrever "como já deve ter reparado "
isso deixa o meu raciocínio mais fluido para a logica da macro.
mas eu coloco um texto explicando a função da variavel quando faço definição dela.

   '------------------------------( Variaveis de Controle )-----------
    Dim Ddo As Variant, ddai As Long    '----------------------Dados
    Dim Tv As Long    ' ------------------Teste de Valores 1 = passa no teste  : 0 = Não passa
    Dim t As Long    '-----------------Teste  de teste  0 = Negativo : 1 = Positivo
    Dim K As Long, F As Long
    ''-----------------------( ORIGEM )----------------------------
    Dim Op As Long, iCo As Long    '----------Direção prioritaria Op="0 = Coluna: 1 = Linha"; Controle Zig Zag Coluna iCo ="0 =Não faz: 1= Faz "
    Dim OLi As Long, OLf As Long, TLo As Long     '------------------------------------Linha inicial e final,"podem ser de quadrante"
    Dim Lio As Long, Lfo As Long    '--------------------Linha inicial e final,Total linhas da origem
...

"selecão de subs" provavelmente vc ja saiba

não, não sabia, tenho que aprender o básico do excel e vba ainda

Sobre goto gosub ... eu penso que bem aplicados pode simplificar grandes projetos
Sobre se perder no fluxo do programa creio que independente de usar ou não, ou ter um monte de variáveis de nomes explicativos da funcionalidade.
Se não for bem estruturado certamente um hora vai dar tudo no "oq mesmo que eu estava fazendo?"

Eu tenho 2 macros enormes que gosub faz papel de amarre e lógica da macro,

ou para sair de um loop e voltar em seguida
claro que se pode fazer isso de farias maneiras diferentes, mas isso vai da capacidade , experiência e conhecimentos de quem faz.
Eu uso bastante goto e gosub, talvez me caia melhor por causa do meu raciocínio simples e linear

resume next

nem sei para que serve "ainda"

Sobre modulos de clases eu vi alguns num ribon bem documentados, tudo em ingles ,
mas para mim que não sabia usar Byref e Byval... larguei de lado assim como os ribons .

att

Variáveis publicas...

Se elas vão ser Redefinidas, não tem o pq se preocupar por valores errados
sobre limpar, talvez as arrays apenas, pq ocupam muita memoria.

Variáveis publicas normalmente vai ter numero limitado e sempre vão ser Redefinidas a cada processo
Talvez isso cause menos impacto,
A não ser no caso de arrays que no fim de processo podem ser redefinidas para um tamanho menor, ou eliminadas.

Ex.

Processo...
macro0 define processo e chama macros envolvidas
macro1 define array com dados da planilha
macro2 usa array
macro3 ajusta array
macro4 passa array para planilha
macro0 chama macro que mata array ou Redim array(1)
Fim Processo[/list:u:ac09nc1y]

pelo menos essa é a minha intenção
se tiver uma ideia melhor, aceito e propostas...
.

Somente é impossíveis até que alguém faça
A logica está presa na irracionalidade humana, e morta nos que se consideram donos da verdade.

"ALGUM MODERADOR ME EXPULSE DO FÓRUM POR FAVOR"

 

Esqueci de comentar um inconveniente disso...
macro 0
pular=100
call macro2
macro2 tem uma variável "pular" com função diferente

nesse caso estou tentando usar um patrão de colocar um X nos finais das variáveis de macros que vão ser chamadas, para evitar conflitos.

bem ainda não sei como o vba se comporta com variáveis de escopo fechado quando uma macro chama a outra e tem variaveis iguais.

Bem como disse, existe muitos poréns para tudo,
E não importando o que se vai usar, tem que planejar e analisar as circunstâncias

Parei de ler pra comentar uma coisa que acho que o Gilmar escreveu:

Segundo: eu prefro criar funções do que subs, apenas pra evitar ficar criando variáveis públicas ou globais.

Ahn ? Acho que causa e consequência não fazem sentido.
Variáveis publicas ou globais podem ser utilizadas igualmente por funções ou subs.
Uma função é uma rotina que retorna valor. Ou seja, uma função bem utilizada deve ter na declaração do nome (que eu chamo de assinatura) um tipo de retorno.
Lembre SEMPRE do que vimos na escola. f(x) = x+1. Em VBA isso seria:

Function f(x as double) as double
f = x + 1
end function

Exemplo:

Function RetornaNada() as String
        RetornaNada = "Nada"
End Function

Ou seja, uma função pode ou não ter parâmetros, mas ela sempre retorna um valor. A galera tem se acostumado a usar function sem retornar valor, isso é permitido só pq VB é uma linguagem ruim, que permite desenvolvimento ruim. Mas isso é fato. Sub não retorna valor, Function retorna valor. Devemos pelas boas práticas SEMPRE seguir essas diretrizes. Isso facilita inclusive para copiar o código do VBE e colar no Visual Studio. Pensem nisso. VS não permite esses erros crassos que o VBE permite.

Assim, estaremos utilizando o termo Function e a funcionalidade de função da maneira correta.
Qualquer rotina que não retorne valor, será uma Sub. Isso não tem nada a ver com o uso de globais. (Desculpa eu colocar seu comentário em epígrafe Gilmar)

*Agora vou continuar a leitura do tópico.

*P.S.: Desculpa discordar de vc em um aspecto Gilmar, e obrigado por ter lembrado do outro tópico.
Eu tenho algumas observações qto ao código do Edcronos, e vou comentar já já...

FF

Aí que tá, o GoTo funciona bem, não é problema, mas todos nós programadores evitamos usar, pois remete ao uso de lógica ruim de programação.
Digo, sua teimosia já é conhecida e eu entendo, não estou falando que vc necessariamente tem que fazer como eu faço.
MAS, eu faria o seguinte, que acho faz mais sentido e evita-se o uso do GoTo, tão famigerado e detonado pela comunidade de desenvovledores.

Sub test()
    If Limit = 1 Then 
        Call inicio
        Call SetorL("dh")
        ColunO = Range(Ti & Li, Cf & Lf).Value2
        'Call Espelhar(ColunO, 1)
        Call Desloc_Array(ColunO, 1, "q", 2)
        Range(Ti & Li, Cf & Lf).Value2 = ColunO
        Call Final
    End If
End Sub

(Eu sempre uso Call para chamar outras rotinas. Adotei esse padrão para ficar bem claro durante a leitura, de que se trata de uma rotina criada.)

Sub Trocar()
    If Limit = 1 Then 
        call inicio

        Call troca_setor(5, 4)
    
        call Final
    End If
End Sub

(Não é que não funcione se não usar o Call, é que fica mais fácil de ler, por qquer desenvolvedor no mundo.)
Viu só, o que precisa pensar é que, se for pra usar o GoTo, tem que ter alguma linha de código depois dele. E é como vc usa o GoSub. Se a linha seguinte é a linha que sai da rotina, use o If Then ... End If...

Os problemas futuros que vc terá com esse tipo de lógica, depender do GoTo, é que enquanto vc está indo de cima pra baixo, vc tem total controle e acha que o mundo é maravilhoso. MAS, quando vc faz um GoTo pra cima, e usar a lógica do GoTo numa linguagem procedural permite isso, o risco de você como programador se perder é grande e outros que vierem mexer nos eu código também.

O GoTo é super legal, mas é um legado de programações antigas em que não era fácil chamar outras rotinas e criar as estruturas de repetição e tal. O ideal é não usar, pois o risco de se acostumar e no futuro fazer alguma merda é muito grande..

Quanto a criar rotinas menores e reaproveitáveis, nem preciso dizer o qto a favor eu sou dessa prática. Eu aprendi com um russo, e claro, nem sempre levo a ferro e fogo, que uma rotina não pode passar da altura de uma tela visível, para facilitar a leitura e compreensão do que ela faz. Eu entendo que a rotina começa depois de sua assinatura, e a declaração de suas variáveis e objetos. Assim tenho mais linhas para desenvolver meu raciocínio.

Enfim... É isso... agora que já li os dois primeiros (tópico e primeira resposta), vou ler o restante e comentar cada uma das respostas.

FF

Em ralação ao números de linhas é bem grande eu quase cheguei perto, agora vai diminuir bastante.

Eu confesso que cheguei nesse limite uma vez na minha carreira. Isso não é um problema quando se organiza o código e escreve rotinas reutilizáveis e dentro de um padrão, de preferência não copiando e colando o conteúdo do gravador de macros. (não estou dizendo que vc faz isso, pelos seus códigos, vc não faz isso.)

realmente exige que use nomes longos para as variáveis de byref e byval, para se indicar a função das variáveis, e posição delas
isso me atrapalhou no inicio, mas...
mas já superei e...

Redefinir variáveis toda vez, faz com que vc utilize mais linhas de código. O que não é tão ruim, desde que vc não esteja dentro de um loop. O fato de serem byRef ou byval, num primeiro momento não faz mta diferença. Com o tempo vc entende e aplica esses conceitos apropriadamente. É importante saber a diferença entre eles e começar a usar o qto antes.

Não é que eu goste de usar nomes curtos,
meu estilo de raciocínio pede isso, "maluquice né"

Sim, maluquice total, kkkk

Sobre variáveis publicas,
infelizmente ainda não pensei em um modo de elimina-las
principalmente as arrays de transporte.

Comece a passar os parâmetros com ByRef, e vc vai ver que seus problemas acabaram.

Mas pelo que entendi do type junto de função, eu teria que redefini-las a cada sub
e não poderia usa-las em cascata nas macros "ou eu não entendi"

Mais uma vez, passe os parâmetros como ByRef..
O uso do Type é muito legal, eu adoro, o Type e o Enum e uso muito. E nunca são globais, pensa só, que maravilha seria. Passa como ByRef, e boas. Exemplinho:

Option Explicit

Public Type Carteira
    Dinheiro As Long
    Moedas As Double
    CartãoDeCrédito As Double
End Type

Sub Qualquer()
Dim MinhaCarteira As Carteira

    MinhaCarteira.Dinheiro = 100
    MinhaCarteira.Moedas = 8.75
    MinhaCarteira.CartãoDeCrédito = 5000
    
    Call ReportarCarteiraByRef(MinhaCarteira)
    
    Debug.Print "Grana Pós Retorno: " & MinhaCarteira.Dinheiro
    Debug.Print "Moedinhas Pós Retorno: " & MinhaCarteira.Moedas
    
End Sub

Sub ReportarCarteiraByRef(ByRef CarteiraQualquer As Carteira)
    Debug.Print "Grana: " & CarteiraQualquer.Dinheiro
    Debug.Print "Moedinhas: " & CarteiraQualquer.Moedas
    'Passamos por ByRef, certo?
    'Isso significa que se eu quiser trocar o valor, ele volta pra rotina que chamou alterado.
    'Vamos trocar os valores então
    CarteiraQualquer.Dinheiro = 50
    CarteiraQualquer.Moedas = 3.5
End Sub

Perceba, o Tipo é publico e global, o uso dele, ou seja, qdo eu o crio como variável/objeto, ela é local, e é passada como parâmetro.

Rode esse código num arquivo novo de Excel, e dê uma olhada na janela imediata (Dentro do VBE, tecle Ctrl+G)

Essa é a diferença entre ByRef e ByVal. Vou escrever um artigo sobre isso e postar no futuro.

Tipos definidos pelo usuários por padrão mesmo que vc não especifique, sempre são considerados ByRef. Se tentar usar ByVal, o VBE vai gritar com vc.

Como assim seleção de sub?

O VBE tem uma caixinha no topo à direita, que vc pode ver as Subs e Functions em ordem alfabética, o que facilita para encontrar o que vc procura.

Att e desculpe pelo livro de historia monótona.

Que monotonia o quê? Quem está aqui adora ler e responder. Adora aparecer e ser reconhecido, ehehehe
De boa, continue mandando. (Pode parecer que não, mas há tempos eu não escrevia tanto pra uma pessoa só, e pior, você nem é mulher, saco! kkkk)

Falei que ia comentar todas as repostas! Por favor pessoal, não se ofendam, eu estou dando dicas pra melhorar o desempenho geral da nação!

chance de cometer um erro de digitação é pequena.

Meu, usa o Ctrl+Espaço, pra forçar o intelisense a completar o nome pra ti...

Já em códigos maiores, é importante usar o "option explicit"

O ideal é usar sempre. Trocar a opção no próprio Excel para ele automaticamente forçar vc a declarar tudo sempre.
- No VBE vá em Ferramentas / Opções
- Na primeira aba, o segundo checkbox, Requerer Declaração de Variáveis (o meu tá em inglês, Require Variable Declaration), veja aí como tá em português.
- Assim, toda vez que vc criar um módulo, pra sempre, o Option Explicit já estará escrito no topo. Acho isso fantástico.

identificando o tipo de variável

Eu fazia isso, sempre.

dim strNome as string
dim lngIdade as Long
dim arrDados as variant

E assim por diante... Até quando descobri que nos modelos mais novos de programação, o Visual Studio impede a compilação caso o dado sendo inserido não seja do tipo certo, e fui aos poucos acostumando a não deifinir o tipo no nome. As vezes ainda faço, mas evito. O nome tem que ser tão descritivo, que torna desnecessário a definição do tipo no nome. Ficando assim:

dim Nome as string
dim Idade as Long
dim Dados as variant

... "goto só se usa uma vez no código e somente para tratamento de erro", ... "on error resume next" não se deve usar nunca.

Exato, "GoTo" é só pro tratamento de erros. "On Error Resume Next", evitar ao máximo, e se usar, melhor ter uma boa justificativa. Eu uso, pouco mas uso, e sempre comento o motivo.

se as variáveis são públicas, acho que não convém ficar limpando os valores dela

Exato, eu procuro usar publicas somente em casos em que é algo que vou usar muito, e quero economizar na passagem de parâmetros. Na maioria são constantes que não devem mudar, tipo:
NomeDoProgramador
GerenteDoProjeto
EmpresaDeDesenvolvimento
ContatosDaEmpresa
NomeDoCliente
NomeDoProjeto
São constantes e o código não as muda. Eu as mudo conforme inicio cada projeto, sempre usando meu modelo.

Eu li um pouco a respeito, assim como li um pouco sobre módulos de classe, mas nunca usei de fato

Eu uso Types, não uso com frequencia as classes. Me perco. Queria aprender tb.
Qto a Types, conforme prometi, vou escrever um artigo sobre ByVal e ByRef, e tb um sobre Types, atendendo a pedidos. Vai ser mais um daqueles meus tutoriais eternos, tipo do Range Dinâmico e tal...

Ufa, to empolgado e respondendo agora vamos pra próxima! rsrsrs

mas eu coloco um texto explicando a função da variavel quando faço definição dela.

Não ficaria mais bonito se fosse assim?
(Copie e cole no VBE, aqui vai ficar feio igual)

'------------------------------( Variaveis de Controle )-----------
Dim Ddo    As Variant, ddai As Long            '..Dados
Dim Tv     As Long                             '..Teste de Valores 1 = passa no teste  : 0 = Não passa
Dim t      As Long                             '..Teste  de teste  0 = Negativo : 1 = Positivo
Dim K      As Long, F As Long

''-----------------------( ORIGEM )----------------------------
Dim Op     As Long, iCo As Long                '..Direção prioritaria Op="0 = Coluna: 1 = Linha";
                                               '..Controle Zig Zag Coluna iCo ="0 =Não faz: 1= Faz "
                                               
Dim OLi    As Long, OLf As Long, TLo As Long   '..Linha inicial e final,"podem ser de quadrante"
Dim Lio    As Long, Lfo As Long                '..Linha inicial e final,Total linhas da origem

Sempre que eu desenvolvo, antes durante e depois, eu fico revendo a rotina para ter certeza que ela parece uma obra de arte, nos mínimos detalhes...

Sobre goto gosub ... eu penso que bem aplicados pode simplificar grandes projetos
Sobre se perder no fluxo do programa creio que independente de usar ou não, ou ter um monte de variáveis de nomes explicativos da funcionalidade.
Se não for bem estruturado certamente um hora vai dar tudo no "oq mesmo que eu estava fazendo?"

Sim, o GoSub cria um ponto no código e vc pode retornar pra ele. É o mesmo que o GoTo, mas com uma marca para onde retornar. Isso pode e vai causar problemas de lógica quando vc abusar do recurso. E mais, ir e voltar dentro da mesma rotina, é o mesmo que criar diversas subrotinas bem estruturadas e chamá-las. A diferença é que seu código fica mais limpo e fácil de entender e dar manutenção. E assim, aquele: "o que mesmo que eu estava fazendo?" acontecerá menos e menos ... Cara, dica de brothers, mais de 10 anos de experiência, evite usar GoTo e o GoSub, comece a forçar esse seu cérebro a usar boas práticas da programação.
Pensa, qtas *subrotinas iguais vc teve que criar em diversas Subs, que poderiam tranquilamente ser uma Sub separada independente ? Economiza número de linhas, facilita leitura, facilita manutenção (muda num lugar só em vez de vários), e ainda tem o mesmo nome do que vc determinou no GoSub...

Resume Next simplesmente manda continuar na próxima linha.
Ele normalmente é usado junto com o On Error:
On Error Resume Next
Se der erro, ignore o erro e vá pra próxima linha.
É arriscado pois seu código não executou uma linha adequadamente, e vc mandou seguir mesmo assim... O programador deve entender as consequencias disso para seguir programando, prevendo o que pode dar errado por causa de um erro que não foi reportado. Por outro lado, mta gente programa e deixa esses On Error Resume Next nos códigos, para poder cobrar e receber o dinheiro, pois os erros acontecem e o próprio sistema não avisa. O cliente está feliz pq não sabe que tá cheio de remendos no código que foi entregue.

Variáveis publicas normalmente vai ter numero limitado e sempre vão ser Redefinidas a cada processo

Mas são linhas desnecessárias, se vc tiver passando os parâmetros, não terá que ficar redefinindo ou ficar lembrando de redefinir todas.

NOTA IMPORTANTE:
A variáveis públicas podem reter valor quando o tempo de execução acabou, ou seja, quando a macro terminou. Na próxima rodada, se um valor tiver sido mantido e vc não tiver reiniciado ela, vc poderia por exemplo, inserir um saldo errado na conta bancária de um cliente... Evitar usar públicas é essencial para reduzir o P.D.M. (Potencial para Dar Merda)

macro 0
pular=100
call macro2
macro2 tem uma variável "pular" com função diferente

Cara, isso pq vc tá usando variáveis curtas. Se vc passa uma variável como parâmetro pra outra rotina, seja função seja sub, não tem pq usar o mesmo nome. Mesmo. Crie um PularLinhas eqto o outro seria um PularColunas...
Explique melhor o que é a variável, no próprio nome. Pensa só que PularX ou PularY não me diz o que cada uma delas faz. E durante a minha leitura do código, precisarei certamente procurar e encontrar os comentários aonde vc explica a diferença. E fato que eu terei que encontrar esses comentários diversas vezes durante essa leitura...

Ufa, acabou...
Espero ter ajudado um pouco...
Ninguém falou de identação, que é importante e essencial para um código com qualidade. Identação é impossível quando se coloca diversas linhas numa linha só, pense nisso Ed !

Abraço, espero continuar com boas argumentações amanhã!

ola fernando, bom dia
sobre goto eu uso as vezes, uso muito é gosub
sim eu sou das antigas...
programei em basic num TK95
milhares de linhas cheias de goto e gosub gravadas numa Fita de audio
aquilo sim era loucura
e não era Goto fim
era goto 5000
na epoca fim uns jogos
o ultimo foi um de 21 e tinha que definir as posições da tela, desenhar as cartas e tudo mais
eu mesclava assembly do Z80 e basic

depois disso não mexi mais nisso até agora esse ano com o VBA
talvez por isso meu modo operante.

Eu redefino as variaveis no inicio
e quando entro num loop todas as variáveis estão com seus conteúdos o mais curto possível "como vc deve ter percebido"

call eu passei a usar nas camadas de macros que tem Byval e Byref, mesmo pq é impossível usar sem call
trato as sub como comandos personalizados.

para não alarga mais ainda...
enfim, teimosia ou não, eu me sinto confortável em programar assim,
para mim é como liberar a lógica e o stress em linhas de comando.

Sobre futuro...
Como falei não trabalho com isso. nem para uso particular.

e em se tratando de entendimento
muito se fala sobre apropriação de direitos,
já li até sobre definir nomes de variáveis malucos e outros truques para não se ter as macros roubadas, "não é por isso que escrevo assim , já escrevia antes de le este artigo".

Então se um dia eu decidir me tornar um programador profissional "oq acho difícil"
Já estou no modo operante de proteção ativo ,
Já pensou o barato que seria na cabeça de alguém tentando entender a lógica das minhas macros com um monte de goto, gosub, chamadas sem call, tio, lio, pio,... e tudo sem mensagens explicando pra que serve?

brincadeira...

mas bem, um monte de coisa que não lembro mais

call eu passei a usar nas camadas de macros que tem Byval e Byref, mesmo pq é impossível usar sem call

É possível sim !
Exemplos de dois jeitos, com e sem o call:

Call FazQualquerCoisa(Parametro1, Parametro2)
FazQualquerCoisa Parametro1, Parametro2

para mim é como liberar a lógica e o stress em linhas de comando.

"Para mim"... é um argumento que não tem como eu convencê-lo a contornar... Por isso, continue como faz, se faz sentido pra vc. As consequências em curto e longo prazo eu já falei. Mas com você, pode ser diferente. Espero que tudo dê sempre certo para suas necessidades (que no final, é o que almejamos sempre. )

Então se um dia eu decidir me tornar um programador profissional "oq acho difícil" Já estou no modo operante de proteção ativo , Já pensou o barato que seria na cabeça de alguém tentando entender a lógica das minhas macros com um monte de goto, gosub, chamadas sem call, tio, lio, pio,... e tudo sem mensagens explicando pra que serve? brincadeira...

kkkkk boa !! É fato que isso tb é um fator que dificulta roubos.

Vamos seguindo... sei que cheguei no tópico depois, e por isso não terei o prazer de ser agraciado com o "Resolvido", mas se puder clicar em "Agradecer" (a mãozinha) nas respostas que foram úteis, eu ficarei bem agradecido. Espero que as respostas tenham ajudado a acrescentar e explicar melhor os conceitos usados hoje em dia...

E como dizia o locutor da televisão, "segue o jogo!"

FF