"Posso comecar minha proxima customizacao em TLPP?" e a pergunta que todo dev novato faz na consultoria. A resposta nao e "sempre" nem "nunca" — e "depende", com criterios objetivos. Esse artigo entrega esses criterios.

Historico em 30 segundos

timeline title Linguagens TOTVS Protheus 1995-2008 : AdvPL classico : xBase + extensoes : sintaxe Clipper 2008-2018 : AdvPL "moderno" : MVC : OO basica : continua xBase no nucleo 2019-2022 : AdvPL++ : tipagem opcional : tentativa de modernizar 2023+ : TLPP : namespaces : tipagem forte : interop com AdvPL : sintaxe estilo C-like

TLPP (TOTVS Language for Protheus Platform) nao substitui AdvPL. Roda no mesmo runtime. Coexiste no mesmo RPO. Voce pode chamar funcao TLPP de codigo AdvPL e vice-versa.

Comparacao tecnica detalhada

CaracteristicaAdvPL classicoTLPP
NamespacesNao tem (prefixos por convencao)Sim, hierarquicos
TipagemDinamica (opcional)Forte e explicita
Tamanho de identificador10 charsIlimitado
OOClass basicaClass + interface + heranca multipla
ModulosTudo globalModular por namespace
Stack traceLimitadoCompleto com line numbers
Rest annotationsManualDecorators @Get @Post
Compatibilidade SmartClient100%100% (gera mesmo bytecode)
Suporte oficial novoManutencaoFoco da TOTVS daqui pra frente
Curva de aprendizado time AdvPL—~2-4 semanas

3 cenarios onde AINDA usar AdvPL classico

  1. Manutencao de codigo legado: 200k linhas de AdvPL no cliente, ninguem vai reescrever do zero. Mantenha em AdvPL e isole modulos novos em TLPP.
  2. Customizacao de relatorios antigos (RDMAKE/Report): muitas APIs especificas ainda exigem AdvPL puro.
  3. Equipe sem tempo de treinar agora: melhor codigo AdvPL bem escrito do que codigo TLPP ruim. Programe a transicao pra Q3/Q4.

5 cenarios onde MIGRAR pra TLPP

  1. Customizacao nova grande (>500 LOC): namespaces poupam horas em conflito de nomes.
  2. API REST nova: decorators TLPP @Get/@Post reduzem boilerplate em ~60%.
  3. Integracao com sistema externo: tipagem forte previne bug de "cString virou cNumber".
  4. Time grande (3+ devs): namespaces evitam que 2 pessoas criem U_FAT_001 diferentes.
  5. Codigo critico (fiscal, financeiro): stack trace completo + tipagem reduz incidentes em producao.

Migracao gradual: namespaces e interop

Voce nao precisa migrar tudo. O segredo: arquivo .tlpp coexiste com .prw no mesmo RPO. TLPP chama AdvPL como funcao normal:

// arquivo: src/archtec/fiscal/CalculadoraIBS.tlpp
namespace archtec.fiscal

#include "tlpp-core.th"

@type class
class CalculadoraIBS
    private data nAliquota as numeric

    public method new(nAliq as numeric) as CalculadoraIBS
        ::nAliquota := nAliq
    return self

    public method calcular(nValor as numeric) as numeric
        local nResultado as numeric

        // Pode chamar funcao AdvPL classica daqui:
        nResultado := nValor * (::nAliquota / 100)
        nResultado := U_AjustarArredondamento(nResultado)  // funcao AdvPL legacy
    return nResultado
endclass

E o AdvPL classico chama TLPP via namespace explicito:

// arquivo legado: src/legacy/MATA001.prw
#include "totvs.ch"

User Function ProcessaPedido(cNumPed)
    Local oCalc
    Local nIBS

    // Instancia classe TLPP a partir do AdvPL
    oCalc := archtec.fiscal.CalculadoraIBS():New(8.6)
    nIBS := oCalc:calcular(1000)

    // continua codigo legacy normal
Return Nil

Benchmarks (direcionais — varia por ambiente)

Sobre os numeros Os benchmarks abaixo sao direcionais — extraidos de medicoes internas em ambientes de cliente, sem suite de teste padronizada publica da TOTVS. Use como ordem de grandeza, nao como medicao laboratorial. Sua mediana vai mudar dependendo de release Protheus, DBAccess, banco e payload.

Mesma logica em AdvPL puro vs TLPP, em ambiente Protheus moderno (12.1.24+):

CenarioAdvPL classicoTLPPDirecao tipica
Loop 100k iteracoes (calculo simples)baseline~baselineEmpate (delta < 5%)
Insert em loop 10k (gargalo no banco)baseline~baselineEmpate (gargalo nao e linguagem)
API REST endpoint /pedidobaseline~baseline ou ligeiramente melhorEmpate ou TLPP -3% a -5%
Parsing JSON com 50 camposbaselinesignificativamente melhorTLPP -25% a -40%
Compile time (10k linhas)baselinemaiorTLPP +30% a +40%

Conclusao direcional Em runtime, TLPP esta empatado ou ligeiramente mais rapido (parsing JSON e endpoints REST tendem a beneficiar). O custo esta no compile time — irrelevante em pipeline de CI, importante em desenvolvimento local. Dev produtivo em TLPP usa hot-reload da TOTVS.

Erros tipicos de quem migra rapido demais

Erro 1 Reescrever modulo inteiro de uma vez. Resultado: 2 meses sem entrega + bug em producao. Faca por feature, nao por modulo.

Erro 2 Importar tudo do AdvPL pro TLPP literalmente. TLPP tem padroes melhores (composition over inheritance). Aproveite a refatoracao.

Erro 3 Ignorar tipagem ("e dinamica mesmo, nao precisa"). O ganho do TLPP e justamente a tipagem. Se voce escreve any em tudo, esta no AdvPL com mais boilerplate.

Erro 4 Build sem TLPP-lint. Codigo TLPP sem linter regride pra qualidade de AdvPL classico.

Receita para a equipe: stack de qualidade

  1. VSCode + extensao oficial TLPP (autocomplete + hot reload)
  2. tlpp-lint com regras estritas no projeto
  3. Git Flow ou GitHub Flow + protecao de branch main (sem commit direto)
  4. CI/CD (veja nosso artigo de pipeline)
  5. Code review obrigatorio em PRs maiores que 20 linhas
  6. TIR com cobertura minima de 70% em codigo novo
  7. Documentacao em Markdown dentro do repositorio (nao em Confluence)

Roadmap recomendado pra 2026-2027

FasePeriodoAcao
1. Pilot1 mes1 dev escreve 1 modulo novo em TLPP. Validar ferramentas.
2. Treinamento2 mesesTime inteiro em curso TLPP + lint configurado
3. Padroes1 mesDocumentar convencoes (namespace, classe, teste)
4. ProducaocontinuoCodigo novo sempre em TLPP. Legacy AdvPL so se mexer.
5. Migracao oportunista2-3 anosCada vez que tocar codigo legado, migra modulo.

Em 24 meses voce tem ~70% do projeto em TLPP sem nenhum freeze de feature. Os outros 30% (codigo morto/raramente tocado) seguem AdvPL e nao incomodam ninguem.

Fale conosco se quer ajuda pra montar a stack TLPP da sua equipe.

Fontes oficiais